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EXECUTIVE  SUMMARY 


The  purpose  of  this  report  is  to  present  various  options  for  transitioning  the  enhanced  Automatic 
Identification  System  (AIS)  capability  developed  by  the  United  States  Coast  Guard  (USCG)  Research  and 
Development  Center  (RDC)  from  a  proof-of-concept  to  an  operational  system.  The  report  will  first  discuss 
the  status  of  the  ongoing  research  and  address  the  attainment  of  the  project's  goals.  A  snapshot  of  the  as-is 
state  of  all  of  the  test  beds  and  demonstration  areas  is  presented  as  the  starting  point  for  the  transition 
discussion.  Since  the  plans  for  transitioning  the  Vessel  Traffic  Service  (VTS)  and  non-VTS  areas  are 
different,  they  are  treated  separately  in  this  report.  Various  transition  options  and  the  costs  of  each  option 
are  detailed  for  the  implementation  of  the  enhanced  AIS  capability  at  all  12  VTS  ports.  Separate  plans  are 
presented  for  moving  responsibility  for  the  demonstration  projects  to  other  government  agencies. 

T  he  AIS  is  an  autonomous  and  continuous  broadcast  system  that  exchanges  maritime  safety/security 
information  between  participating  vessels  and  shore  stations.  In  addition  to  providing  a  means  for  maritime 
administrations  to  effectively  track  the  movement  of  vessels  in  coastal  and  inland  waters,  AIS  can  be  a 
means  to  transmit  information  to  ships  in  port  or  underway  that  contributes  to  safety-of-navigation  and 
protection  of  the  environment.  This  includes  meteorological  and  hydrographic  data,  carriage  of  dangerous 
cargos,  safety  and  security  zones,  status  of  locks  and  aids-to-navigation,  and  other  port/waterway  safety- 
information.  In  the  United  States,  it  is  intended  that  this  information  be  transmitted  from  shore-side  AIS 
base  stations  in  a  binary  message  format  as  part  of  an  expanded  Vessel  Traffic  Service  (VTS)  provided  by 
the  United  States  Coast  Guard  (USCG).  The  vision  for  the  expanded  use  of  AIS  within  VTS  areas  is  to 
reduce  workload  on  ship  bridges  by  using  less  Very  High  Frequency  (VHF)  voice  and  making  crucial 
information  available  when  needed  for  decision-making,  improve  VTS  efficiency  by  reducing  voice 
communications  with  the  possibility  of  “silent”  traffic  advisories  and  automatic  encounter  lists,  and  improve 
VTS  services  with  better,  and  more,  information  to  mariner  in  a  usable  format,  that  is  timely  and  less 
intrusive. 

A  functional  requirements  study  was  conducted  to  develop  requirements  for  marine  information  that  could 
be  broadcast  by  USCG  VTS  Centers  primarily  via  AIS  binary  messages.  The  AIS  stakeholder  groups 
produced  a  list  of  information  items  that  they  deemed  necessary  to  improve  safety.  Most  of  these 
information  items  are  covered  in  three  new  proposed  binary  messages  -  Environmental,  Area  Notice  and 
Waterways  Management.  The  remaining  information  items  can  be  sent  using  existing  AIS  messages. 

Several  test  beds  were  established  to  test  the  new  proposed  binary  messages.  The  primary  test  bed  for  this 
effort  was  established  in  Tampa,  FL.  Secondary  demonstrations  were  established  in  the  Stellwagen  Bank  (as 
an  early  demonstration  of  the  use  of  Area  Notice  Messages)  and  Columbia  River  (as  a  test  bed  for  an  area 
with  multiple  AIS  base  stations). 

The  test  beds  proved  successful  and  the  primary  objective  of  this  report  is  to  investigate  options  to  transition 
AIS  transmit  from  a  research  effort  into  an  operational  system  that  is  implemented  at  all  VTS  ports.  A 
secondary  objective  is  to  transition  support  for  all  non-VTS  programs  away  from  the  Coast  Guard. 
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Table  1 .  VTS  Ports  alternatives  summarized. 


Option  1  - 
Implement 
Prototype  at  all 
12  VTS 

Option  2  - 
Operational 
Prototype 
Model 

Option  3  - 
PAWSS  Phase  1 
Transmit  Model 

Option  4  -  PAWSS 
Phase  II  Transmit 
Model 

Option  5  - 
PAWSS  Phase  III 
Transmit  Model 

FF/QM 

RDC 

Application 

At  RDC 

RDC 

Application 

At  VTS 

RDC  Application 

At  VTS 

RDC  Application 

At  VTS 

PAWSS 

ARI 

RDC  app  at 

RDC 

RDC  app  at 

VTS 

PAWSS 

PAWSS 

PAWSS 

VDL 

Monitoring 

RDC  app  at 

RDC 

RDC  app  at 

VTS 

RDC  app  at  VTS 

RDC  app  at  VTS 

PAWSS 

Message 

Display 

TV32  at  VTS 

TV32  at  VTS 

TV32  at  VTS 

PAWSS 

PAWSS 

Message 

Creation 

TV32  at  VTS 

TV32  at  VTS 

TV32  at  VTS 

PAWSS 

PAWSS 

Cost 

$1,251,150 

$1,063,800 

$766,200 

$905,200 

$1,691,550 

Cost 

W/CGDN+ 

$1,118,550 

$619,800 

$633,600 

$772,600 

$1,636,800 

Cost  for  just 

2  existing 
sites 

$273,075 

N/A 

$192,850 

N/A 

N/A 

Pros 

Simplest  option, 

replicates 

current 

operations. 

Back-end 

processes 

separate 

modules. 

Back-end 

processes 

separate 

modules 

Uses  PAWSS 

Phase  1  interface. 

Back-end 

processes 

separate 

modules 

Single  GIS  system 
for  operator  Back¬ 
end  processes 
separate  modules 

Single  system  for 
operator 

Cons 

Puts  operational 
burden  on  RDC. 
Multiple  GIS 
systems  for 
operator 

Doesn't  make 
use  of  Phase  1 
interface. 
Multiple  GIS 
systems  for 
operator. 

Multiple  GIS 
systems  for 
operator 

Requires  additional 

PAWSS 

development 

Requires  most 

PAWSS 

development 

Puts  back-end 
processes  within 
GIS. 

Table  1  summarizes  the  five  options  that  have  been  considered  for  the  transition  process  at  all  VTS  ports. 
The  options  differ  primarily  in  the  amount  of  software  integration  that  must  be  done  with  the  Ports  and 
Waterways  Safety  System  (PAWSS).  The  options  have  been  ordered  from  least  amount  of  integration  to  the 
most.  Option  1,  Prototype  Implementation,  would  keep  the  current  configuration.  In  this  option,  RDC  would 
continue  to  operate  and  monitor  all  back-end  operations  until  some  future  transition  to  Nationwide  AIS 
(NA1S)  Phase  2.  The  back-end  operations  are  the  computers  and  software  that  monitor  the  AIS  message 
loading,  generate  the  AIS  messages  from  sensor  data,  and  send  the  messages  out  an  AIS  base  transmit 
station.  Option  2,  Operational  Implementation,  would  mirror  the  configuration  used  in  the  Tampa  test  bed 
where  there  is  no  connection  to  the  PAWSS,  but  the  back-end  operations  would  be  moved  from  RDC  to 
each  VTS.  Option  3,  PAWSS  Phase  1  Transmit,  would  mirror  the  configuration  as  planned  for  the  Port 
Arthur  test  where  the  binary  messages  are  provide  to  PAWSS  for  transmission,  but  the  other  back-end 
processes  are  moved  from  RDC  to  each  VTS  for  monitoring.  Option  4,  PAWSS  Phase  2  Transmit,  moves 
all  message  creation  and  display  capability  into  PAWSS  but  keeps  the  back-end  processes  separate.  The 
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back-end  processes  are  moved  from  RDC  to  each  VTS  for  monitoring.  Option  5,  PAWSS  Phase  3  Transmit, 
moves  all  of  the  processes  into  PAWSS  -  message  creation  and  display,  as  well  as  the  back-end  processes. 

A  cost  analysis  is  presented  for  each  option. 

The  recommended  option  is  Option  4  because  it  consolidates  AIS  binary  message  creation  and  display 
capability  into  the  existing  operational  Geographic  Information  System  (GIS),  or  PAWSS,  and  keeps  the 
back-end  processes  separate.  Option  4  is  higher  cost  than  Options  2  and  3,  but  much  of  that  cost  is  the 
upgrade  to  the  PAWSS  software,  a  one  time  cost. 

A  plan  to  meet  the  secondary  objective  of  transitioning  support  for  all  non- VTS  programs  away  from  the 
Coast  Guard  is  also  presented.  The  National  Oceanographic  and  Atmospheric  Administration,  NOAA,  has 
agreed  to  take  over  operation  of  the  Stellwagen  Bank  AIS  Transmit  operations.  The  Volpe  Center  will  take 
over  the  AIS  Transmit  operations  in  the  Columbia  River  as  part  of  their  contracted  support  to  the  Columbia 
River  Pilots  (COLRIP). 

The  Coast  Guard  standard  for  shipboard  Electronic  Charting  System  (ECS)  software  is  in  a  period  of 
transition.  Currently  Coast  Guard  cutters  use  a  variety  of  software,  none  of  which  support  enhanced  AIS 
capabilities.  We  strongly  recommend  that  CG-761  and  CG-762  work  closely  with  C2CEN  with  regards  to 
the  integration  of  AIS  transmit  capabilities  into  the  USCG’s  ECS  software.  If  these  added  capabilities  were 
developed  into  Sperry's  navigation  software,  when  Sperry  's  navigation  software  becomes  the  standard  for 
Coast  Guard  cutters  and  small  boats  the  Coast  Guard  personnel  onboard  could  immediately  take  advantage 
of  the  added  capabilities. 

The  AIS  transmit  capability  should  be  considered  for  inclusion  in  the  USCG  Enterprise  Service  Bus  (ESB), 
as  the  recently  published  Semper  Paratus  Enterprise  Architecture  Realization  (SPEAR)  Implementation 
Guide  specifically  states  that  connections  between  Coast  Guard  services  and  systems  should  use  the  ESB. 
However,  inclusion  of  AIS  transmit  in  the  SPEAR  CG  Enterprise  Architecture  is  a  major  effort.  It  will 
require  a  cost/benefit  analysis,  revision  of  current  architecture,  and  upgrade  to  all  software  in  the  data 
processing.  A  detailed  evaluation  for  including  AIS  transmit  in  SPEAR  is  bey  ond  the  scope  of  this  transition 
plan,  so  a  separate  study  should  be  performed  to  evaluate  the  feasibility  (and  architecture)  and  effectiveness 
and  provide  recommendations  on  implementation. 
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Automatic  Identification  System 
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Area  Notice  Message 
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Aeronautical  Radio  Incorporated 

AtoN 

Aids  to  Navigation 
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Coast  Guard  Data  Network 
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DGNSS 

Differential  Global  Navigation  Satellite  System 
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Electronic  Charting  System 
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Enterprise  Service  Bus 
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IP2COMM 
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Maritime  Mobile  Service  Identity 
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Operation  System  Center 
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Research  and  Development  Center 
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Radio  Technical  Commission  for  Maritime  Services 

SAR 

Search  and  Rescue 
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SPEAR 
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1  INTRODUCTION 

The  purpose  of  this  report  is  to  present  various  options  for  transitioning  the  enhanced  AIS  capability 
developed  by  the  USCG  Research  and  Development  Center  (RDC)  from  a  proof-of-concept  to  an 
operational  system.  The  report  will  first  discuss  the  status  of  the  ongoing  research  and  address  the 
attainment  of  the  project’s  goals.  A  snapshot  of  the  as-is  state  of  all  of  the  test  beds  and  demonstration  areas 
is  presented  as  the  starting  point  for  the  transition  discussion.  Since  the  plans  for  transitioning  the  VTS  and 
non- VTS  areas  are  different,  they  are  treated  separately  in  this  report.  Various  transition  options  and  the 
costs  of  each  option  are  detailed  for  the  implementation  of  the  enhanced  AIS  capability  at  all  12  VTS  ports. 
Separate  plans  are  presented  for  moving  responsibility  for  the  demonstration  projects  to  other  government 
agencies. 

1.1  Project  Background 

The  Automatic  Identification  System  (AIS)  is  an  autonomous  and  continuous  broadcast  system  that 
exchanges  maritime  safety/security  information  between  participating  vessels  and  shore  stations.  In  addition 
to  providing  a  means  for  maritime  administrations  to  effectively  track  the  movement  of  vessels  in  coastal 
and  inland  waters,  AIS  can  be  a  means  to  transmit  information  to  ships  inport  or  underway  that  contributes 
to  safety-of-navigation  and  protection  of  the  environment.  This  includes  meteorological  and  hydrographic 
data,  carriage  of  dangerous  cargos,  safety  and  security  zones,  status  of  locks  and  aids-to-navigation,  and 
other  port/waterway  safety  information.  In  the  United  States,  it  is  intended  that  this  information  be 
transmitted  from  shore-side  AIS  base  stations  in  a  binary  message  format  as  part  of  an  expanded  Vessel 
Traffic  Service  (VTS)  provided  by  the  United  States  Coast  Guard  (USCG). 

The  AIS  does  a  great  job  informing  the  VTS  about  vessel  position  and  identification,  but  it  can  also  be  used 
as  a  VTS  tool  for  communication  by  utilizing  the  transmit  capability  and  AIS  binary  messages.  For 
clarification  purposes  transmit  is  defined  to  include  both  AIS  broadcast  and  addressed  messages.  T  he 
current  AIS  specification,  ITU-1371 -3  [1  ]  defines  26  different  AIS  messages  shown  in  Table  2.  Some  of 
these  message  types  can  be  grouped  into  categories  applicable  to  AIS  transmit:  message  types  16,  20,  22, 
and  23  can  be  considered  telecommands  that  can  be  used  by  a  VTS  for  channel  management;  message  types 
12,  13,  and  14  can  be  used  for  safety-related  text  messages;  and  message  types  6,  7,  8,  21, 25,  and  26  are  all 
binary'  messages  that  can  be  used  for  information  transfer.  The  messages  listed  in  bold  have  been  used  in  the 
testing  discussed  in  this  report. 

The  AIS  transmit  capability  is  not  a  broadband  digital  connection—  there  is  limited  bandwidth  available,  so 
it  is  not  intended  to  be  used  for  generic  data  transfer  of  information  that  can  be  obtained  by  other  means. 

The  AIS  transmit  capability  can  make  required  information  available  to  the  mariners  and  other  users 
without  using  voice  communications;  especially  time-critical  or  dynamic  information.  The  vision  for  the 
expanded  use  of  AIS  within  VTS  areas  is  to: 

1)  Reduce  workload  on  ship  bridges  by  using  less  Very  High  Frequency  (VHF)  voice  and  making 
crucial  information  available  when  needed  for  decision-making. 

2)  Improve  VTS  efficiency  by  reducing  voice  communications  with  the  possibility  of  “silent”  traffic 
advisories  and  automatic  encounter  lists. 

3)  Improve  VTS  services  with  better,  and  more,  information  to  mariner  in  a  usable  format,  that  is 
timely  and  less  intrusive. 
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Table  2.  AIS  message  types  (those  in  bold  are  part  of  this  testing). 


ID# 

AIS  Message  Description 

1,2,3 

Position  Reports  -  autonomous  (au),  assigned  (as),  or  interrogated  (in) 

4 

Base  Station  Report  -  UTC/date  position,  slot  nr 

5 

Class  A  Report  -  static  and  voyage  related  data 

6,  7,  8 

Binary  Message  -  addressed,  acknowledge  or  broadcast 

9 

SAR  aircraft  position  report 

10,  11 

UTC/Date  -  enquiry  and  response 

12, 13, 14 

Safety  Text  Message  -  addressed,  acknowledge  or  broadcast 

15 

Interrogation  -  request  for  specific  messages 

16 

Assignment  Mode  Command 

17 

Binary  Message  -  DGNSS  Correction 

18,19 

Class  B  Reports  -  position  &  extended 

20 

Data  Link  Management  -  reserve  slots 

21 

ATON  Report  -position  &  status 

22 

Channel  Management 

23 

Group  Assignment 

24 

Class  B-CS  Static  Data 

25 

Binary  Message  -  single-slot 

26 

Binary  Message  -  multi-slot  (STDMA) 

1.2  Project  Goals 

The  goals  of  this  effort  are  to  reduce  voice  communications  and  improve  navigation  safety  and  efficiency. 

This  can  be  best  achieved  by  the  following  objectives: 

•  Identify  and  prioritize  the  types  of  information  that  should  be  broadcast  using  AIS  binary  messages  - 
information  that  is  available,  important  to  the  mariner,  and  provided  to  the  mariner  in  a  timely 
fashion  and  in  a  useable  format. 

•  Develop  recommendations  for  transmission  and  shipboard  display  standards. 

•  Obtain  data  to  support  reduced  voice  communications  and  improved  navigation. 

To  meet  these  objectives  the  U.S.  Coast  Guard  Research  and  Development  Center  (RDC)  initiated  the  AIS 

Transmit  Project.  There  are  three  main  efforts  to  this  project: 

1)  Determine  functional  requirements.  The  goal  is  to  establish  what  the  AIS  capability  within  VTS 
should  be  which  involves  identifying  and  gathering  information  from  various  AIS/VTS 
Stakeholders. 

2)  Establish  test  bed(s).  The  goal  is  to  test  concepts,  ideas,  draft  standards,  and  validate  requirements 
prior  to  USCG  implementation  by  establishing  a  test  bed  in  an  existing  VTS  area  and  encouraging 
active  participation  by  marine  pilots. 

3)  Establish  a  Working  Group  within  the  RTCM  (Radio  Technical  Commission  for  Maritime  Services) 
to  review  current  VTS  AIS  capability  in  US  waters  and  recommend  “consolidated”  AIS  binary 
messages  (for  regional  and  international  implementation)  and  to  identify  needed  changes  in  AIS 
equipment  to  support  new  capabilities. 
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1.3  Transition  Plan  Objectives 

The  initial  goals  of  the  project  have  mostly  been  met.  Since  the  proof-of-concept  has  proven  to  be  successful 
it  is  time  now  to  move  the  system  into  an  operational  environment.  The  primary  objective  is  to  transition 
AIS  transmit  from  a  research  effort  into  an  operational  system  that  is  implemented  at  all  VTS  ports.  A 
secondary  objective  is  to  transition  support  for  all  non- VTS  programs  away  from  the  Coast  Guard. 

There  are  a  variety  of  ways  that  the  first  objective  can  be  met  depending  upon  where  the  required  processes 
are  implemented.  The  test  bed  work  has  shown  what  processes  are  required  to  implement  the  enhanced  AIS 
capability,  but  there  are  options  as  to  where  this  capability  resides  (RDC,  VTS,  etc)  and  what  software 
application  implements  the  process  (RDC  software  or  PAWSS).  This  Transition  Plan  investigates  several 
alternatives  that  explore  the  range  of  options  for  where  the  capability  is  implemented.  This  ranges  from 
extending  the  system  as  currently  implemented  with  no  PAWSS  integration  and  all  back-end  processes 
located  at  RDC  to  the  other  extreme  of  having  all  capability  integrated  into  PAWSS  located  at  each  VTS. 
There  are  also  several  middle-ground  options  with  varying  levels  of  capability  integrated  into  PAWSS.  The 
options  are  numerically  ordered  in  increasing  levels  of  PAWSS  integration. 

While  the  first  objective  deals  with  transitioning  to  an  operational  Coast  Guard  environment  and  extending 
the  enhanced  AIS  capability  to  all  12  VTS  ports,  the  second  objective  concerns  removing  capability  from 
Coast  Guard  operational  control  to  some  Other  Government  Agency  (OGA).  This  is  a  good  example  for 
how  an  OGA  might  be  able  to  implement  AIS  transmit  in  areas  where  the  Coast  Guard  does  not  have 
transmitters  and  for  applications  that  the  Coast  Guard  does  not  have  a  mission  requirement  or  funding.  A 
detailed  plan  is  provided  for  how  the  two  demonstration  sites  can  be  shifted  from  Coast  Guard  to  OGA 
operational  control  without  negatively  impacting  service. 

1.4  Report  Structure 

The  report  is  laid  out  in  several  sections.  Section  1  provides  a  project  overview.  The  progress  to  date  on 
meeting  the  initial  project  goals  is  described  in  Section  2.  Next,  Section  3  details  the  current  state  of  the 
Tampa  test  bed  and  two  demonstration  areas.  Section  4  provides  the  costs  assessment  of  each  of  the  5 
alternatives.  The  cost  model  for  the  various  VTS  Physical  Oceanographic  Real-Time  System  (PORTS) 
transition  alternatives,  covering  all  of  the  various  costs  considered  with  the  alternatives,  is  contained  in 
Appendix  B.  Section  5  provides  the  details  on  the  transition  plan  to  move  the  two  demonstration  areas  from 
Coast  Guard  operational  control  to  that  of  another  agency.  Section  6  brings  up  a  few  other  considerations 
such  as  vessel  software,  training,  and  doctrine.  And  finally.  Section  7  provides  guidance  for  choosing  the 
best  option,  as  well  as  some  recommendations  for  future  considerations. 

2  PROGRESS  TO  DATE 

Over  the  past  2+  years  RDC  supported  by  Alion  Science  and  Technology  (Alion)  has  worked  towards 
meeting  the  project  goals.  This  progress  is  highlighted  in  each  of  the  following  sub-sections.  A  more 
comprehensive  description  of  the  efforts  can  be  found  in  the  Preliminary  Summary  Report  [2]. 
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2.1  Requirements  Report 

A  functional  requirements  study  was  conducted  by  Alion  for  RDC  to  develop  requirements  for  marine 
information  that  could  be  broadcast  by  USCG  VTS  Centers  primarily  via  AIS  binary  messages  [3].  The 
study  focused  on  gathering  stakeholder  requirements  and  determining  the  capabilities  of: 

•  Information  providers. 

•  Information  disseminators. 

•  Shipboard  equipment  manufacturers. 

•  End  users  (mariners). 

The  goal  was  to  identify  and  prioritize  the  types  of  information  that  should  be  broadcast  using  AIS  binary 
messages. 

There  were  three  over-riding  concerns  as  to  what  would  be  considered  to  be  relevant  AIS  binary  message 
information. 

1)  Important  (i.e.,  useful  4  crucial)  to  the  mariner  for  decision  support. 

2)  Reliably  available  and  without  interruption. 

3)  Provided  in  a  timely  fashion  in  a  usable  format. 

During  the  data  collection,  representatives  from  each  of  the  stakeholder  groups  listed  above  were  asked  for 
their  input  on  20  possible  data  items  that  could  potentially  be  transmitted  using  AIS  binary  messages.  They 
were  also  asked  for  input  on  additional  items  for  the  list.  These  responses  were  tabulated  and  evaluated  and 
those  most  important  to  all  segments  were  identified.  The  information  types  that  were  important  to  both  are 
listed  in  Table  3.  The  information  items  were  also  categorized  in  the  table  to  group  them  into  a  small 
number  of  messages.  Most  of  these  are  covered  in  the  three  proposed  binary  messages  (Environmental,  Area 
Notice  and  Waterways  Management).  The  two  messages  not  covered  in  the  proposed  binary  messages  are 
covered  by  the  existing  AIS.  The  Emergency  Messages  (EM)  can  be  sent  as  text  Safety  Messages  (message 
types  12  and  14)  and  Aids  to  Navigation  (AtoN)  outages/changes  can  be  covered  with  the  existing  AtoN 
message  (message  type  21). 


Table  3.  Data  desired  by  users  and  VTSs. 


Environmental  Data 

Area  Notice 

Waterways  Management 
Information 

Tides  (now  and  predicted) 

AtoN  outages  /  changes 

Lock  order 

Water  levels 

Ice  advisories 

Bridge  openings/closings 

Water  current  velocity  (speed  and 
direction) 

Dredge  locations  /  information 

Procession  order  for  narrow 
channels 

Visibility  /  fog 

Security  zone  locations  /  information 

Air  and  water  temperature 

Restricted  operation  areas  due  to 
low  visibility  or  security 

Emergency  Messages 

Wind  speed  and  direction 

Location  and  information  on  marine 
events  /  regattas 

Precipitation 

Anchorage  management 
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The  conclusions  from  the  Requirements  Study  were  clear.  First,  there  is  a  need  and  a  desire  to  have  more 
information  flow  from  the  VTS  to  the  mariners  as  data  rather  than  voice.  There  is  a  large  amount  of  data 
available  that  could  improve  the  safety  and  efficiency  of  navigation  within  the  VTS  Area  of  Responsibility 
(AOR).  However,  both  mariners  and  VTS  operators  can  quickly  become  overloaded  with  the  current 
amount  of  voice  traffic.  Using  digital  data  distribution  as  an  alternative  to  voice  makes  the  most  sense  for 
increasing  the  data  available  to  the  mariners  without  overloading  them  and  using  AIS  binary  messages  to 
accomplish  this  is  a  good  solution. 

Second,  flexibility  is  very  important.  A  system  must  be  able  to  send  the  necessary  data  to  the  people  who 
want  it  based  on  area  of  operation.  The  users  are  a  diverse  group;  different  user  communities  (tugs,  ferries, 
pilots,  etc)  and  even  the  same  user  communities  in  different  harbor  areas  all  have  different  information 
needs  -  there  is  no  universal  answer.  The  one  commonality  to  all  users  is  that  the  information  must  be 
displayed  in  a  way  that  is  user-friendly.  User-friendly  is  defined  here  as  information  that  is  clear, 
uncluttered,  and  does  not  overwhelm  the  mariner  with  excessive  or  irrelevant  information.  It  is  our 
recommendation  that  equipment  manufacturers  work  closely  with  their  customers  to  decide  the  best  way  to 
display  transmitted  information. 

Third,  the  existing  capabilities  of  AIS  were  reviewed  to  see  if  the  desired  data  could  be  accommodated.  As  a 
result  of  this  analysis,  it  was  determined  that  the  needs  cannot  be  met  with  existing  message  types.  Keeping 
in  mind  the  need  for  flexibility  to  handle  the  varied  users  communities  and  geographic  differences,  three 
new  generic  binary  messages  have  been  developed  and  are  being  defined  as  an  RTCM  standard  [4J.  These 
three  messages,  along  with  existing  AtoN  and  Safety  Related  Text  messages  should  be  able  to  handle  all  of 
the  desired  information  transfer. 

2.2  Test  Beds 

The  primary  test  bed  for  this  effort  was  established  in  Tampa,  FL.  Details  on  the  original  design  and  the 
implementation  plan  are  in  [5J.  Secondary  demonstrations  were  established  in  the  Stellwagen  Bank  (as  an 
early  demonstration  of  the  use  of  Area  Notice  messages)  and  Columbia  River  (as  a  test  bed  for  an  area  with 
multiple  AIS  base  stations). 

One  of  the  major  outcomes  of  the  test  bed  was  the  identification  and  quantification  of  the  processes  needed 
in  order  to  create  and  transmit  binary  messages.  These  processes  and  the  test  bed  applications  to  implement 
those  processes  are  shown  in  Figure  1 . 
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Figure  1.  Binary  message  creation  processes. 


2.3  RTCM  Working  Group  Binary  Messages 


ITU  1371-3  [1]  defines  AIS  binary  messages;  these  are  now  being  referred  to  as  Application  Specific 
Messages  but  either  term  may  be  used.  AIS  message  type  6  is  an  addressed  binary  message  and  type  8  is  a 
broadcast  binary  message.  All  type-certified  AIS  radios  understand  the  basic  binary  message  types. 
However,  the  “payload'’  of  a  binary  message  (the  application  data)  is  NOT  defined.  Figure  2  shows  a 
graphical  representation  of  an  AIS  message  type  8  (broadcast  binary).  The  only  part  defined  is  the  16  bit 
Application  Identifier  which  is  made  up  of  the  Designated  Access  Code  (DAC)  and  Functional  Identifier 
(FI).  The  remainder  of  the  message  (the  Application  data)  is  undefined  by  1371-3  and  is  not  dealt  with  at  the 
radio  level.  All  AIS  radios  pass  this  application  data  via  the  radio’s  serial  or  network  port  to  the  presentation 
layer  for  processing. 
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Message  DAC/ 

Header  (16 

(40bits)  bits) 


Application  Data 
(up  to  952  bits) 


Figure  2.  Broadcast  binary  message  specification. 


I'he  Radio  Technical  Commission  for  Maritime  Services  (RTCM)  is  an  international  non-profit  scientific, 
professional  and  educational  organization.  RTCM  Special  Committees  (SC)  within  the  organization  provide 
a  forum  in  which  government  and  non-government  members  work  together  to  develop  technical  standards 
and  consensus  recommendations  in  regard  to  issues  of  particular  concern.  A  working  group  called  “T  he 
Expanded  Use  of  AIS  within  VTS”  was  established  under  SC  121  to  develop  the  AIS  Application  Specific 
(binary)  messages  necessary  to  transmit  the  information  types  listed  in  Table  3.  The  RTCM  messages  are 
contained  in  the  draft  RTCM  Standard  121xx.l  [4],  The  three  messages  are  summarized  here. 


2.3.1  Environmental  Message 

The  RTCM  Working  Group  developed  an  Environmental  Message  format  that  would  accommodate 
meteorological  and  hydrological  data  throughout  the  U.S.  The  goal  was  to  accommodate  the  information 
transfer  requirements  of  all  of  the  stakeholders:  National  Oceanic  and  Atmospheric  Administration  (NOAA) 
Physical  Oceanographic  Real-Time  System  (PORTS),  the  NOAA  National  Data  Buoy  Center  (NDBC),  and 
the  US  Army  Corps  of  Engineers  (USACE).  The  Env  ironmental  Message  is  intended  for  a  wide  variety  of 
environmental  data,  including:  current  flow,  water  level,  water  temperature,  visibility,  and  air  gap.  The 
message  has  the  ability  to  provide  both  real-time  and  forecast  data.  In  order  to  maximize  flexibility,  this 
message  can  be  used  to  transmit  from  1  to  8  sensor  reports  (a  1  sensor  report  uses  1  slot  while  a  message 
with  8  sensor  reports  requires  5  slots).  These  sensor  reports  can  be  data  from  one  location  or  from  multiple 
locations.  In  addition,  the  data  does  not  need  to  be  sent  at  the  same  update  rate  allowing  data  that  changes 
more  rapidly  to  be  sent  more  often  than  slowly  changing  data.  Static  data  such  as  sensor  position  can  be  sent 
even  less  frequently. 

Each  Environmental  Message  has  56  bits  of  standard  header  and  from  1  to  8  sensor  reports  (112  bits  each). 
Each  sensor  report  has  27  bits  of  common  data  leaving  85  bits  for  sensor  data.  There  are  a  variety  of  sensor 
types  that  can  be  transmitted  using  this  message;  4  bits  gives  16  possible  values,  these  are  listed  in  Table  4. 
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Table  4.  Environmental  message  types. 


Value 

Description 

Notes 

0 

Site  Location 

1 

Station  ID 

2 

Wind 

3 

Water  level 

4 

Vertical  Current  Profile  (2D) 

5 

Vertical  Current  Profile  (3D) 

6 

Honzontal  Current  Profile 

7 

Sea  state 

8 

Salinity 

9 

Weather 

10 

Air  gap/  Air  draft 

11 

(Reserved  for  future  use) 

12 

(Reserved  for  future  use) 

13 

(Reserved  for  future  use) 

14 

(Reserved  for  future  use) 

15 

(Reserved  for  future  use) 

2.3.2  Area  Notice  Message 

The  purpose  of  the  Area  Notice  is  to  transmit  information  that  pertains  to  a  region  or  area.  For  example  a 
security  zone,  an  area  of  fog  or  dredging  operations.  The  areas  that  are  being  defined  can  be  circles, 
rectangles,  polygons,  or  sectors.  They  can  also  be  defined  as  a  simple  point  or  series  of  points  (polyline). 
The  Area  Notice  Message  can  be  defined  by  the  union  of  multiple  subareas.  For  instance,  if  it  includes  3  or 
more  subareas  that  are  points,  then  the  total  area  is  defined  by  connecting  the  points.  This  message  can  also 
be  used  to  convey  advisory  lines  or  tracks. 

The  intent  with  an  Area  Notice  Message  is  to  broadcast  dynamic  information  (i.e.  information  that  is  time 
dependent).  These  messages  are  to  be  used  for  a  specific  time  period  and  will  automatically  timeout  at  the 
end  of  the  period.  If  the  Area  Notice  Message  must  be  in  place  longer,  then  a  new  Area  Notice  Message 
must  be  transmitted  with  a  new  start  and  end  time.  It  should  only  be  used  to  convey  pertinent  time-critical 
navigation  safety  information  to  mariners  or  authorities,  and  not  as  a  means  to  convey  information  already 
provided  by  official  nautical  charts  or  publications. 

2.3.3  Waterways  Management  Message 

The  Waterways  Management  Message  can  be  used  to  facilitate  vessel  traffic  movement  in  confined  waters. 
More  “directive”  than  advisory,  this  message  can  be  broadcast  (e.g.,  information  for  all  ships  or  a  group  of 
ships)  or  addressed  (e.g.,  information/direction  to  a  single  ship).  Examples  include:  lock,  gate,  narrows,  or 
single  passage  area.  There  are  two  sub-types  of  this  message;  1)  for  providing  a  position/name  of  the 
waterway  feature,  and  2)  for  providing  a  list  of  vessels  and  their  sequence  order/times.  Specific  information 
for  each  vessel  includes:  sequence  time,  direction,  and  vessel  Maritime  Mobile  Service  Identity  (MMSI). 
The  complete  list  of  message  types  is  contained  in  Table  5. 
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Table  5.  Waterways  management  message  types. 


Value 

Description 

Value 

Description 

0 

Lock 

7 

Traffic  Advisory 

1 

Gate 

8 

Cleared  to  Enter  /  Proceed 

2 

Narrows 

9  1 

Not  Cleared  to  Enter  /  Do  not  Proceed 

3 

Bridge 

10 

Proceed  to  Berth 

4 

Restricted  channel  --  one  vessel  at  a  time  - 
could  be  alternating  directions  -  no  passing  or 
overtaking 

11 

Proceed  to  (defined  in  linked  Text 

Msg) 

5 

Estimated  Arrival  Time 

12-15 

Undefined 

6 

Assigned  Arrival  Time 

3  CURRENT  STATE 

The  following  subsections  describe  the  current  state  of  each  of  the  test  bed/demonstration  areas  that  need  to 
be  transitioned. 

3.1  Tampa  Test  Bed 

The  Tampa  test  bed  has  been  the  primary  test  site  to  evaluate  processes  and  perfonnance  for  future 
implementation  at  all  Coast  Guard  VTS  sites.  A  system  diagram  is  shown  in  Figure  3.  The 
Fetcher/Formatter  (FF),  Queue  Manager  (QM)  and  AIS  Radio  Interface  are  all  running  on  a  computer  at 
RDC  and  monitored  by  Alion.  The  binary  messages  are  sent  to  the  AIS  base  stations  in  Largo.  FL  that  is 
shared  with  the  VTS  operations  system  (Norcontrol™  software  by  Kongsberg).  The  NA1S  receiver  at 
Palmetto  is  used  as  the  monitor  site  and  to  calculate  VDL  loading  using  Internet  Protocol  to  Communication 
Port  Conversion  Software,  IP2COMM,  (both  AIS  LIser  and  IP2COMM  are  also  running  on  the  QM 
computer).  Alion  and  VTS  personnel  are  monitoring  the  overall  system  performance  to  ensure  that  the  data 
is  getting  to  the  users.  Transview,  EM  Decoder,  and  ARINC’s  PilotMate™  software  are  used  both  at  RDC 
and  the  VTS  to  monitor  operations.  Transview  in  conjunction  with  VTS  Info  Manager  is  used  at  the  VTS  to 
create  Area  Notice  Messages. 
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RDC,  New  London  4 


Figure  3.  Tampa  test  bed  system  diagram. 


3.2  Stellwagen  Bank  Demonstration 


Display  Computer 
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Figure  4.  Stellwagen  Bank  demonstration  diagram. 
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The  Stellwagen  bank  demonstration  has  been  a  joint  effort  between  the  USCG  R&D  Center  (with  Alion 
Science  &  Technology  support)  and  NOAA  National  Marine  Sanctuary  (with  University  of  New  Hampshire 
(UNH)  and  Cornell  University  support).  A  system  diagram  is  shown  in  Figure  4.  The  Fetcher/Formatter  is 
currently  being  run  at  Cornell  and  monitored  by  UNH  (both  under  contract  to  NOAA).  The  Queue  Manager 
(QM)  is  running  on  a  computer  at  RDC  and  monitored  by  Alion.  The  AIS  Radio  Interface  (ARI)  is  running 
on  a  computer  at  Provincetown  and  monitored  by  Alion.  The  Nationwide  AIS  (NAIS)  receivers  in  the 
Boston  area  are  used  as  monitor  sites  and  to  calculate  VHF  Data  Link  (VDL)  loading  using  Internet 
Protocol  to  Communication  Port  Conversion  Software  (IP2COMM)  (AIS  User  and  IP2COMM  are  also 
running  on  the  QM  computer).  Alion  and  UNH  are  monitoring  the  overall  system  performance  to  ensure 
that  the  data  is  getting  to  the  users. 

3.3  Columbia  River  Demonstration 

The  Columbia  River  Demonstration  has  been  a  joint  effort  between  the  USCG  R&D  Center  (with  Alion 
Science  &  Technology  support)  and  the  Columbia  River  Pilots  (with  Volpe  NTSC  support).  A  system 
diagram  is  shown  in  Figure  5.  The  Fetcher/Formatter  (FF),  Queue  Manager  and  AIS  Radio  Interface  are  all 
running  on  a  computer  at  RDC  and  monitored  by  Alion.  The  AIS  base  stations  (Green  Mountain  and  Meglar 
Mountain)  are  operated/monitored  for  the  COLRIP  by  the  Volpe  Center.  The  two  base  stations  are  operated 
in  repeater  mode  so  that  all  traffic  received  is  retransmitted.  The  NAIS  receiver  at  Cape  Disappointment  is 
used  as  the  monitor  site  and  to  calculate  VDL  loading  using  IP2COMM  (both  AIS  User  and  IP2COMM  are 
also  running  on  the  same  computer  as  the  QM).  Alion  and  Volpe  are  monitoring  the  overall  system 
performance  to  ensure  that  the  data  is  getting  to  the  users.  Transview  (TV32)  and  EM  Decoder  software  are 
used  at  RDC  to  monitor  operations. 
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Figure  5.  Columbia  River  demonstration  system  diagram. 
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4  VTS  PORTS  IMPLEMENTATION  ALTERNATIVES 


A  variety  of  options  have  been  considered  for  the  transition  process.  The  options  differ  primarily  in  the 
amount  of  software  integration  that  must  be  done  with  the  PAWSS  system.  The  options  have  been  ordered 
from  least  amount  of  integration  to  the  most.  For  each  option  the  location  and  application  used  for  each  of 
the  major  processes  is  listed.  The  highlights  of  each  option  along  w  ith  the  total  costs  are  displayed  in  Table 
6. 


Table  6.  VTS  Ports  alternatives  summarized. 


Option  1  -  RDC- 
hosted  PAWSS 
Phase  1  Transmit 

Option  2  - 
Operational 
w/out  PAWSS 

Option  3  - 
PAWSS  Phase  1 
Transmit 

Option  4  - 
PAWSS  Phase 

II  Transmit 

Option  5  - 
PAWSS  Phase 

III  Transmit 

FF/QM 

RDC  app.  at  RDC 

RDC  app  at 

VTS 

RDC  app  at 

VTS 

RDC  app  at 

VTS 

PAWSS 

ARI 

PAWSS 

RDC  app  at 

VTS 

PAWSS 

PAWSS 

PAWSS 

VDL 

Monitoring 

RDC  app  at  RDC 

RDC  app  at 

VTS 

RDC  app  at 

VTS 

RDC  app  at 

VTS 

PAWSS 

Message 

Display 

TV32  at  VTS 

TV32  at  VTS 

TV32  at  VTS 

PAWSS 

PAWSS 

Message 

Creation 

TV32  at  VTS 

TV32  at  VTS 

TV32  at  VTS 

PAWSS 

PAWSS 

One-time 

Costs 

$123,000 

$120000 

$123,000 

$352,000 

$1,380,000 

Per-site  Costs 

$86,363 

$78,650 

$45,250 

$35,250 

$8,400 

Total  Cost 

$1,251,150 

$1,063,800 

$766,200 

$905,200 

$1,691,550 

Total  Cost 
W/CGDN+ 

$1,118,550 

$619,800 

$633,600 

$772,600 

$1,636,800 

Cost  for  2 
existing  sites 

$273,075 

N/A 

$192,850 

N/A 

N/A 

Pros 

Simplest  option, 
replicates  current 
operations  Back¬ 
end  processes 
separate 
modules. 

Back-end 

processes 

separate 

modules. 

Uses  PAWSS 
Phase  1 

interface.  Back¬ 
end  processes 
separate 
modules. 

Single  GIS 
system  for 
operator.  Back¬ 
end  processes 
separate 
modules. 

Single  system 
for  operator. 

Cons 

Puts  operational 
burden  on  RDC 
Multiple  GIS 
systems  for 
operator 

Doesn’t  make 
use  of  Phase  1 
interface. 

Multiple  GIS 
systems  for 
operator. 

Multiple  GIS 
systems  for 
operator 

Requires 

additional 

PAWSS 

development. 

Requires  most 

PAWSS 

development 

Puts  back-end 
processes  within 
GIS 

Each  of  the  5  options  are  described  in  the  sub-sections  below.  In  addition,  the  costs  for  each  option 
according  to  the  cost  model  described  in  Appendix  B  are  summarized.  A  complete  cost  table  is  provided  as 
a  separate  Excel  document. 
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Another  consideration  is  whether  to  centralize  or  de-centralize  the  major  functions.  Some  functions  lend 
themselves  to  being  centralized  while  others  do  not.  The  Fetcher/Formatter  (access  to  PORTS  data)  and 
Queue  Manager  (routing,  prioritizing,  and  queuing  functions)  functions  can  be  centralized.  The  AIS  Radio 
Interface  (communications  with  the  AIS  Base  Station)  and  VHF  Data  Link  (VDL)  load  monitoring  could  be 
centralized  depending  upon  whether  or  not  the  AIS  Base  Stations  support  network  access  and  whether  the 
load  monitoring  is  done  using  the  Base  Stations  or  NAIS  receivers.  The  message  creation  functions 
(specifically  Area  Notice  creation)  require  local  knowledge  and  would  best  be  done  locally  for  quality 
control  reasons. 

4.1  Option  1  —  RDC-Hosted  PAWSS  Phase  I 

Option  1  keeps  the  current  configuration  as  described  above  but  extends  it  to  the  rest  of  the  VTS  ports.  In 
this  option,  RDC  would  continue  to  operate  and  monitor  all  back-end  operations  until  some  future  transition 
to  NAIS  Phase  2.  Tampa  and  Port  Arthur  would  be  kept  as  implemented  during  the  proof-of-concept  testing 
and  enhanced  AIS  capability  would  be  added  to  the  remaining  10  VTS  ports,  using  the  PAWSS  Phase  I 
interface  (as  described  in  Option  3)  for  the  8  remaining  PAWSS  ports  and  the  non-standard  approach 
(Option  2)  for  LA/LB  and  Louisville.  The  applications  used  for  the  major  processes  and  the  locations  of  the 
computers  running  those  processes  are  listed  in  Table  7. 

Table  7.  Option  1  -  RDC-hosted  PAWSS  Phase  1,  applications  and  locations. 


Process 

Application 

Location 

FF/QM 

RDC  applications 

RDC 

ARI 

RDC  application 

RDC 

VDL  Monitoring 

RDC  application 

RDC 

Display  of  binary  messages 

TV32 

VTS 

Message  Creation 

VTS  Info  Manager/TV32 

VTS 

The  cost  summary  is  listed  in  Table  8.  The  rationale  for  each  cost  category  follows. 

4.1.1  Initial  Transition  /  Installation  Costs 

Hardware:  For  this  option  a  server  computer  is  needed  to  run  the  back-end  applications  and  a  desktop 
computer  to  run  TV32  and  VIM.  It  is  assumed  that  one  server  at  RDC  can  run  the  applications  for  2  VTS 
sites.  This  is  needed  for  each  site;  new  computers  are  included  for  the  two  existing  sites  (Tampa  and  Port 
Arthur). 

Network:  One  network  line  is  needed  for  the  VTS  center  (since  PAWSS  handles  the  connections  to  the  AIS 
base  stations,  existing  CGDN+  links  can  be  used).  This  includes  the  initial  installation  cost  and  the  recurring 
cost  for  5  years.  This  is  needed  for  each  site. 

RDC  Softw  are  Development:  This  cost  is  estimated  at  320  hours  of  development  time  to  make  the  RDC 
software  applications  operationally  ready.  This  is  a  one-time  cost  for  the  entire  group  of  VTSs. 

RDC  Software  Documentation:  This  cost  is  estimated  at  80  hours  of  development  time  to  fully  document 
the  RDC  software  applications  operationally  and  create  user  manuals.  This  is  a  one-time  cost  for  the  entire 
group  of  VTSs. 
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PAWSS  Software  Development  and  Documentation:  The  PAWSS  development  to  support  the  PAWSS 
Phase  I  model  has  already  been  completed  and  paid  for. 

Installation  of  RDC  Hardware  and  Software:  This  is  the  cost  to  install  the  computers  listed  under 
hardware  and  software  applications  at  each  site.  This  cost  is  estimated  at  1  week  (40  hours)  to  prepare  the 
hardware  and  software  configuration  for  each  site  and  then  another  week  (40  hours)  for  the  installation  at 
each  site.  In  addition.  16  hours  is  estimated  to  arrange  the  details  of  the  network  line.  Site  survey  costs  are 
assumed  to  be  performed  by  existing  on-site  personnel  and  are  addressed  under  the  personnel  section.  This 
is  needed  for  each  site. 

4.1.2  Training  Costs 

Training  on  Non-PAWSS  Software:  This  is  the  time  required  to  conduct  training  with  the  users  on  the 
non-PAWSS  software  applications.  No  training  is  required  for  the  users  on  the  back-end  applications  since 
they  are  at  RDC  so  training  is  only  needed  on  TV32  and  VIM.  This  is  estimated  at  1  days  (8  hours).  This  is 
needed  for  each  site. 

Training  Development  for  Non-PAWSS  Software:  This  is  the  time  required  to  develop  the  training 
materials  for  the  non-PAWSS  software  applications.  This  is  estimated  at  80  hours  of  development  time. 

This  is  a  one-time  cost  for  the  entire  group  of  VTSs. 

Training  on  PAWSS  Software:  There  is  minimal  enhanced  PAWSS  capability  under  this  option  -  just  the 
ability  to  accept  messages  from  the  QM.  Training  has  been  estimated  at  1  day.  This  is  needed  for  each  site. 

Training  Development  for  PAWSS  Software:  This  is  the  time  required  to  develop  the  training  materials 
for  the  enhanced  PAWSS  capabilities.  This  is  estimated  at  20  hours  of  development  time.  This  is  a  one-time 
cost  for  the  entire  group  of  VTSs. 

4.1.3  Maintenance  Costs 

Monitoring  Processes:  This  is  the  time  required  for  someone  to  monitor  operations  of  the  QM/FF/ARI 
software.  Since  all  back-end  processes  would  be  running  at  RDC  under  this  option  there  is  some  savings  due 
to  the  consolidation  in  one  location.  This  is  estimated  to  require  1  hour  per  day  (365  hrs/yr)  for  ALL  sites. 

To  align  with  the  spreadsheet  calculations  this  amount  is  shown  as  1/12  for  each  of  the  12  sites. 

Initial  Response:  This  is  the  time  required  for  someone  to  take  initial  corrective  action  for  all  non-PAWSS 
software.  This  is  activity  that  takes  little  time  such  as  restarting  computers  or  applications.  This  is  estimated 
to  require  Vi  hour  per  week  (26  hrs/yr).  This  is  needed  for  each  site. 

Second  Level  Response:  This  is  the  time  required  for  someone  to  take  corrective  action  for  system  failures 
of  all  non-PAWSS  software.  This  is  assumed  to  be  able  to  be  done  remotely  (no  travel  required).  This  is 
estimated  to  require  4  hours  per  outage,  with  outages  estimated  to  occur  3  times  per  computer  per  year.  This 
is  needed  for  each  site. 

Hardware  Maintenance:  This  is  assumed  to  be  covered  under  manufacturer’s  warranty  so  there  are  no 
costs  estimated  for  this. 
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Software  Maintenance:  It  is  assumed  that  PAWSS  maintenance  is  already  covered  under  the  existing 
contract.  The  cost  for  five  years  of  maintenance  on  the  non-PAWSS  software  is  estimated  at  20%/year  for  5 
years  of  the  development  cost. 


Table  8.  Option  1  -  RDC-hosted  PAWSS  Phase  1,  summary  costs. 


Cost  Category 

Per  Site  Costs 
(5yrs) 

Fixed/One  Time  Initial 
Cost 

Initial  Transition  / 
Installation  Costs 

Hardware 

$2,000 

0 

Network 

$6,250 

$0 

RDC  software  Development 

$0 

$48,000 

RDC  software  Documentation 

$0 

$12,000 

PAWSS  Software  development  &  documentation 

$0 

$0 

Installation  of  RDC  h/w  and  s/w  site  survey 

$0 

$0 

Prep  site  specific  details  for  installation 

$6,000 

$0 

Arrange  network  lines 

$2,400 

$0 

Onsite  for  installation 

$6,000 

$0 

Training 

Costs 

Training  -  on  non  PAWSS  s/w 

$1,200 

$0 

Training  Development  -  on  non  PAWSS  s/w 

0 

$12,000 

Training  -  on  PAWSS  s/w 

$1,200 

$0 

Training  Development  -  on  PAWSS  s/w 

$0 

$3,000 

Maintenance 

Costs 

Monitoring  processes  -  non-PAWSS  s/w 

$22,813 

$0 

Initial  Response  at  VTS  -  for  non-PAWSS  s/w 

$19,500 

$0 

2nd  Level  Response  at  VTS  -  for  non-PAWSS  s/w 

$18,000 

Hardware  Maintenance 

$0 

$0  j 

Software  Maintenance  -  non  PAWSS 

0 

$48,000 

4.1.4  Cost  Totals 

Using  the  costs  in  Table  8,  the  total  cost  per  site  (for  five  years)  and  the  total  fixed  (system-wide)  cost  can 
be  totaled.  The  total  cost  per  site  is  multiplied  by  the  12  sites  and  added  to  the  total  fixed  cost  then  the 
additional  network  costs  for  the  three  non-PAWSS  sites  are  added  in  to  arrive  at  the  total  cost.  These  totals 
are  shown  in  Table  9.  One  option  shown  in  this  table  is  the  CGDN+  option.  For  this  option  the  non-PAWSS 
applications  are  certified  for  use  on  the  CGDN+  (which  is  a  one-time  cost).  This  allows  CGDN+  network 
connections  to  be  used  so  all  of  the  network  costs  can  be  subtracted  out  y  ielding  a  new  (lower)  total  cost. 

A  second  option  priced  out  in  this  summary  table  is  to  just  maintain  the  existing  test  beds  at  Tampa  and  Port 
Arthur  with  the  back-end  processes  and  monitoring  at  RDC.  In  this  estimate  since  the  equipment  is  already 
installed  a  site  survey  is  not  needed;  however  new  computers  would  be  purchased  for  each  site  to 
standardize  the  test  beds.  Additionally,  a  network  line  is  already  available  at  Tampa  so  this  cost  is 
subtracted.  All  other  cost/site  and  fixed  costs  are  the  same.  The  total  is  for  just  these  two  sites. 
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Table  9.  Option  1  -  RDC-hosted  PAWSS  Phase  I,  cost  totals. 


Per-site  Costs 
for  All  Ports 

(12) 

Additional  Per- 
site  Costs  for 
Non-PAWSS 
Ports  (3) 

Fixed  Cost  for 
Entire  System 

Total  Cost  for 
All  Sites  for 

5  Years 

Implement  Option  1  at  12  Sites 

$85,363 

$34,600 

$123,000 

$1,251,150 

With  CGDN+  Certification  Option 

$76,713 

n/a 

$198  000 

$1,118,550 

Port  Arthur 
cost 

Tampa  cost 

Fixed  Cost  for 
Entire  System 

Total  Cost  for 
both  sites  for  5 
years 

Status  Quo  Option  -  Just  Maintain 
Tampa  and  Port  Arthur  Sites 

$79,363 

$70,713 

$123,000 

$273,075 

4.2  Option  2  -  Operational  Without  PAWSS 

Option  2  mirrors  the  configuration  used  in  the  Tampa  test  bed.  This  capability  would  be  pushed  out  to  all  12 
VTS  ports.  There  is  no  connection  to  PAWSS,  but  the  back-end  processes  (FF/QM/ARI)  would  be  moved 
from  RDC  to  each  VTS.  The  applications  used  for  the  major  processes  and  the  locations  of  the  computers 
running  those  processes  are  listed  in  Table  10;  the  gray  shading  indicates  elements  in  the  table  that  are 
different  from  the  previous  option. 

Table  10.  Option  2  -  operational  without  PAWSS,  applications  and  locations. 


Process 

Application 

Location 

FF/QM 

RDC  applications 

VTS 

ARI 

RDC  application 

VTS 

VDL  Monitoring 

RDC  application 

VTS 

Display  of  binary  messages 

TV32 

VTS 

Message  Creation 

VTS  Info  Manager/TV32 

VTS 

The  cost  summary  is  listed  in  Table  1 1 .  The  rationale  for  each  cost  category  follows. 

4.2.1  Initial  Transition  /  Installation  Costs 

Hardware:  For  this  option  a  server  computer  is  needed  to  run  the  back-end  applications  and  a  desktop 
computer  to  run  TV32  and  VIM.  This  is  needed  for  each  site. 

Network:  One  network  line  is  needed  for  each  of  the  4  AIS  base  stations  and  1  line  for  the  VTS  center.  This 
includes  the  initial  installation  cost  and  the  recurring  cost  for  5  years.  This  is  needed  for  each  site. 

RDC  Softw  are  Development:  This  cost  is  estimated  at  320  hours  of  development  time  to  make  the  RDC 
software  applications  operationally  ready.  This  is  a  one-time  cost  for  the  entire  group  of  VTSs. 

RDC  Software  Documentation:  This  cost  is  estimated  at  80  hours  of  development  time  to  fully  document 
the  RDC  software  applications  operationally  and  create  user  manuals.  This  is  a  one-time  cost  for  the  entire 
group  of  VTSs. 
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PAWSS  Software  Development  and  Documentation:  This  option  does  not  need  any  PAWSS 
development. 

Installation  of  RDC  Hardware  and  Software:  This  is  the  cost  to  install  the  computers  listed  under 
hardware  and  software  applications  at  each  site.  This  cost  is  estimated  at  1  week  (40  hours)  to  prepare  the 
hardware  and  software  configuration  for  each  site  and  then  another  week  (40  hours)  for  the  installation  at 
each  site.  In  addition,  16  hours  is  estimated  to  arrange  the  details  of  each  network  line  for  a  total  of  80 
hours.  Site  survey  costs  are  assumed  to  be  performed  by  existing  on-site  personnel  and  are  addressed  under 
the  personnel  section.  This  is  needed  for  each  site. 

4.2.2  Training  Costs 

Training  on  non-PAWSS  Software:  This  is  the  time  required  to  conduct  training  with  the  users  on  the 
non-PAWSS  software  applications  (FF,  QM,  ARI,  TV32,  and  VIM).  This  is  estimated  at  2  days  (16  hours). 
This  is  needed  for  each  site. 

Training  Development  for  Non-PAWSS  Software:  This  is  the  time  required  to  develop  the  training 
materials  for  the  non-PAWSS  software  applications.  This  is  estimated  at  80  hours  of  development  time. 

This  is  a  one-time  cost  for  the  entire  group  of  VTSs. 

Training  on  PAWSS  Software:  This  is  the  time  required  to  conduct  training  with  the  users  on  the 
enhanced  PAWSS  capabilities.  Since  there  is  no  enhanced  PAWSS  capability  under  this  option  there  are  no 
costs. 

Training  Development  for  PAWSS  Software:  This  is  the  time  required  to  develop  the  training  materials 
for  the  enhanced  PAWSS  capabilities.  Since  there  is  no  enhanced  PAWSS  capability  under  this  option  there 
are  no  costs. 

4.2.3  Maintenance  Costs 

Monitoring  Processes:  This  cost  is  assumed  to  be  performed  by  existing  on-site  personnel  and  is  addressed 
under  the  personnel  section  in  Appendix  B. 

Initial  Response:  This  cost  is  assumed  to  be  performed  by  existing  on-site  personnel  and  is  addressed  under 
the  personnel  section  in  Appendix  B. 

Second  Level  Response:  This  is  the  time  required  for  someone  to  take  corrective  action  for  system  failures 
of  all  non-PAWSS  software.  This  is  assumed  to  be  able  to  be  done  remotely  (no  travel  required).  T  his  is 
estimated  to  require  4  hours  per  outage,  with  outages  estimated  to  occur  3  times  per  computer  per  year.  This 
is  needed  for  each  site. 

Hardware  Maintenance:  This  is  assumed  to  be  covered  under  manufacturer’s  warranty  so  there  are  no 
costs  estimated  for  this. 

Software  Maintenance:  It  is  assumed  that  PAWSS  maintenance  is  already  covered  under  the  existing 
contract.  The  cost  for  five  years  of  maintenance  on  the  non-PAWSS  software  is  estimated  at  20%/year  for  5 
years  of  the  development  cost. 
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Table  1 1 .  Option  2  -  operational  without  FAWSS,  summary  costs. 


Cost  Category 

Per  Site  Costs 
(5yrs) 

Fixed/One  Time 
Initial  Cost 

Initial  Transition  / 
Installation  Costs 

Hardware 

$3,000 

$0 

Network 

$31,250 

$0 

RDC  software  Development 

$0 

$48,000 

RDC  software  Documentation 

$0 

$12,000 

PAWSS  Software  development  &  documentation 

$0 

$0 

Installation  of  RDC  h/w  and  s/w  site  survey 

$0 

$0 

Prep  site  specific  details  for  installation 

$6,000 

$0 

Arrange  network  lines 

$12,000 

$0 

Onsite  for  installation 

$6,000 

$0 

Training 

Costs 

Training  -  on  non  PAWSS  s/w 

$2,400 

$0 

Training  Development  -  on  non  PAWSS  s/w 

$0 

$12,000 

Training  -  on  PAWSS  s/w 

r$o 

$0 

Training  Development  -  on  PAWSS  s/w 

^$0 

$0 

Maintenance 

Costs 

Monitoring  processes  -  non-PAWSS  s/w 

$0 

$0 

Initial  Response  at  VTS  -  for  non-PAWSS  s/w 

$0 

$0 

2nd  Level  Response  at  VTS  -  for  non-PAWSS  s/w 

$18,000 

Hardware  Maintenance 

$0 

$0 

Software  Maintenance  -  non  PAWSS 

0 

$48,000 

4.2.4  Cost  Totals 

Using  the  costs  in  Table  1 1  the  total  cost  per  site  (for  five  years)  and  the  total  fixed  (system-wide)  cost  can 
be  totaled.  The  total  cost  per  site  is  multiplied  by  the  12  sites  and  added  to  the  total  fixed  cost  to  arrive  at  the 
total  cost.  These  totals  are  shown  in  Table  12.  The  additional  option  shown  in  this  table  is  the  CGDN+ 
option.  For  this  option  the  non-PAWSS  applications  are  certified  for  use  on  the  CGDN+  (which  is  a  one¬ 
time  cost).  This  allows  CGDN+  network  connections  to  be  used  so  all  of  the  network  costs  can  be 
subtracted  out  yielding  a  new  (lower)  total  cost. 


Table  12.  Option  2  -  operational  without  PAWSS,  cost  totals. 


Per-site  Costs  for 

All  Ports  (12) 

Fixed  Cost  for 
Entire  System 

Total  Cost  for  All 
Sites  for  5  years 

Implement  Option  2  at  12  sites 

$78,650 

$120,000 

$1,063,800  1 

With  CGDN+  Certification  Sub-option 

$35,400 

$195,000 

$619,800 

4.3  Option  3  -  PAWSS  Phase  I  Transmit  Model 

Option  3  mirrors  the  configuration  as  planned  for  the  Port  Arthur  test.  The  binary  messages  are  provide  to 
PAWSS  for  transmission,  but  the  back-end  processes  are  moved  from  RDC  to  each  VTS  for  monitoring. 
This  capability  would  be  pushed  out  to  all  9  PAWSS  ports  and  the  Option  2  model  would  be  used  at  the  3 
non-PAWSS  ports.  The  applications  used  for  the  major  processes  and  the  locations  of  the  computers 
running  those  processes  are  listed  in  Table  13;  the  gray  shading  indicates  elements  in  the  table  that  are 
different  from  the  previous  option. 
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Table  13.  Option  3  -  PAWSS  Phase  I  transmit,  applications  and  locations. 


Process 

Application 

Location 

FF/QM 

RDC  applications 

VTS 

ARI 

PAWSS 

VTS 

VDL  Monitoring 

RDC  application 

VTS  ' 

Display  of  binary  messages 

TV32 

VTS 

Message  Creation 

VTS  Info  Manager/TV32 

VTS 

The  cost  summary  is  listed  in  Table  14.  The  rationale  for  each  cost  category  follows. 

4.3.1  Initial  Transition  /  Installation  Costs 

Hardware:  For  this  option  a  server  computer  is  needed  to  run  the  back-end  applications  and  a  desktop 
computer  to  run  TV32  and  VIM.  This  is  needed  for  each  site. 

Network:  One  network  line  is  needed  for  the  VTS  center  (since  PAWSS  handles  the  connections  to  the  AIS 
base  stations,  existing  CGDN+  links  can  be  used).  This  includes  the  initial  installation  cost  and  the  recurring 
cost  for  5  years.  This  is  needed  for  each  site. 

RDC  Software  Development:  T  his  cost  is  estimated  at  320  hours  of  development  time  to  make  the  RDC 
software  applications  operationally  ready.  This  is  a  one-time  cost  for  the  entire  group  of  VTSs. 

RDC  Softw  are  Documentation:  This  cost  is  estimated  at  80  hours  of  development  time  to  fully  document 
the  RDC  software  applications  operationally  and  create  user  manuals.  This  is  a  one-time  cost  for  the  entire 
group  of  VTSs. 

PAWSS  Software  Development  and  Documentation:  The  PAWSS  development  to  support  the  Phase  I 
Transmit  model  has  already  been  completed  and  paid  for. 

Installation  of  RDC  Hardware  and  Software:  This  is  the  cost  to  install  the  computers  listed  under 
hardware  and  software  applications  at  each  site.  This  cost  is  estimated  at  1  week  (40  hours)  to  prepare  the 
hardware  and  software  configuration  for  each  site  and  then  another  week  (40  hours)  for  the  installation  at 
each  site.  In  addition,  16  hours  is  estimated  to  arrange  the  details  of  the  network  line.  Site  survey  costs  are 
assumed  to  be  performed  by  existing  on-site  personnel  and  are  addressed  under  the  personnel  section.  This 
is  needed  for  each  site. 


4.3.2  Training  Costs 

Training  on  Non-PAWSS  Software:  This  is  the  time  required  to  conduct  training  with  the  users  on  the 
non-PAWSS  software  applications  (FF,  QM,  TV32,  and  VIM).  This  is  estimated  at  2  days  (16  hours).  This 
is  needed  for  each  site. 


Training  Development  for  Non-PAWSS  Software:  This  is  the  time  required  to  develop  the  training 
materials  for  the  non-PAWSS  software  applications.  This  is  estimated  at  80  hours  of  development  time. 
This  is  a  one-time  cost  for  the  entire  group  of  VTSs. 


Training  on  PAWSS  Software:  There  is  minimal  enhanced  PAWSS  capability  under  this  option  -  just  the 
ability  to  accept  messages  from  the  QM.  Training  has  been  estimated  at  1  day.  This  is  needed  for  each  site. 
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Training  Development  for  PAWSS  Software:  This  is  the  time  required  to  develop  the  training  materials 
for  the  enhanced  PAWSS  capabilities.  This  is  estimated  at  20  hours  of  development  time.  This  is  a  one-time 
cost  for  the  entire  group  of  VTSs. 

4.3.3  Maintenance  Costs 

Monitoring  Processes:  This  cost  is  assumed  to  be  performed  by  existing  on-site  personnel  and  is  addressed 
under  the  personnel  section  in  Appendix  B. 

Initial  Response:  This  cost  is  assumed  to  be  performed  by  existing  on-site  personnel  and  is  addressed  under 
the  personnel  section  in  Appendix  B. 

Second  Level  Response:  This  is  the  time  required  for  someone  to  take  corrective  action  for  system  failures 
of  all  non-PAWSS  software.  This  is  assumed  to  be  able  to  be  done  remotely  (no  travel  required).  This  is 
estimated  to  require  4  hours  per  outage,  with  outages  estimated  to  occur  3  times  per  computer  per  year.  The 
estimate  is  $0  for  corrective  action  for  the  PAWSS  software  because  it  is  covered  under  the  existing 
maintenance  contract.  'This  is  needed  for  each  site. 

Hardware  Maintenance:  This  is  assumed  to  be  covered  under  manufacturer's  warranty  so  there  are  no 
costs  estimated  for  this. 

Software  Maintenance:  It  is  assumed  that  PAWSS  maintenance  is  already  covered  under  the  existing 
contract.  The  cost  for  five  years  of  maintenance  on  the  non-PAWSS  software  is  estimated  at  20%/year  for  5 
years  of  the  development  cost. 


Table  14.  Option  3  -  PAWSS  Phase  1  Transmit,  Summary  Costs. 


Cost  Category 

Per  Site  Costs 
(5yrs) 

Fixed/One  Time  Initial 
Cost 

Initial  Transition  / 
Installation  Costs 

Hardware 

$3,000 

$0 

Network 

$6,250 

$0 

RDC  software  Development 

$0 

$48,000 

RDC  software  Documentation 

$0 

$12,000 

PAWSS  Software  development  &  documentation 

$0 

$0 

Installation  of  RDC  h/w  and  s/w.  site  survey 

$0 

$0 

Prep  site  specific  details  for  installation 

$6,000 

$0 

Arrange  network  lines 

$2400 

$0 

Onsite  for  installation 

$6,000 

$0 

Training 

Costs 

Training  -  on  non  PAWSS  s/w 

$2,400 

$0 

Training  Development  -  on  non  PAWSS  s/w 

$0 

$12,000 

Training  -  on  PAWSS  s/w 

$1,200 

$0 

Training  Development  -  on  PAWSS  s/w 

$0 

$3,000 

Maintenance 

Costs 

Monitoring  processes  -  non-PAWSS  s/w 

$0 

$0 

Initial  Response  at  VTS  -  for  non-PAWSS  s/w 

$0 

$0 

2nd  Level  Response  at  VTS  -  for  non-PAWSS  s/w 

$18,000 

Hardware  Maintenance 

h$o 

$0 

Software  Maintenance  -  non  PAWSS 

$48,000 
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4.3.4  Cost  Totals 

Using  the  costs  in  Table  14  the  total  cost  per  site  (for  five  years)  and  the  total  fixed  (system-wide)  cost  can 
be  totaled.  The  total  cost  is  calculated  as  follows:  9  times  the  total  PAWSS  ports  per-site  costs  plus  3  times 
the  total  non-PAWSS  ports  per-site  costs  plus  the  total  fixed  cost.  These  totals  are  shown  in  Table  1 5.  One 
option  shown  in  this  table  is  the  CGDN+  option.  For  this  option  the  non-PAWSS  applications  are  certified 
for  use  on  the  CGDN+  (which  is  a  one-time  cost).  This  allows  CGDN+  network  connections  to  be  used  so 
all  of  the  network  costs  can  be  subtracted  out  yielding  a  new  (lower)  total  cost. 

A  second  option  priced  out  in  this  summary  table  is  to  just  maintain  the  existing  test  beds  at  Tampa  and  Port 
Arthur  with  the  back-end  processes  and  monitoring  moved  to  each  VTS.  In  this  estimate  since  the 
equipment  is  already  installed  a  site  survey  is  not  needed;  however  new  computers  would  be  purchased  for 
each  site  to  standardize  the  test  beds.  Additionally,  a  network  line  is  already  available  at  Tampa  so  this  cost 
is  subtracted.  All  other  cost/site  and  fixed  costs  are  the  same.  The  total  is  for  just  these  two  sites. 


Table  15.  Option  3  -  PAWSS  Phase  I  Transmit  Model,  Cost  Totals 


Per-site 
Costs  for 
PAWSS  Ports 
(9) 

Per-site 
Costs  for 
Non-PAWSS 
Ports  (3) 

Fixed  Cost 
for  Entire 
System 

Total  Cost  for 
All  Sites  for  5 
Years 

Implement  Option  3  at  12  Sites 

$45,250 

$78,650 

$123,000 

$766,200 

With  CGDN+  Certification  Option 

$36,500 

$35,400 

$198,000 

$633,600 

Port  Arthur 
Cost 

Tampa  Cost 

Fixed  Cost 
for  Entire 
System 

Total  Cost  for 
both  Sites  for 

5  Years 

Status  Quo  Option  - 

Just  Maintain  Tampa  and  Port  Arthur  Sites 

$39  250 

$30,600 

$123,000 

$192,850 

4.4  Option  4  -  PAWSS  Phase  II  Transmit  Model 

Option  4  moves  all  message  creation  and  display  capability  into  PAWSS  but  keeps  the  back-end  processes 
separate.  The  back-end  processes  are  moved  from  RDC  to  each  VTS  for  monitoring.  This  capability  is 
pushed  out  to  all  9  PAWSS  ports  with  the  3  non-PAWSS  ports  transitioned  as  in  Option  2.  The  applications 
used  for  the  major  processes  and  the  locations  of  the  computers  running  those  processes  are  listed  in  Table 
1 6;  the  gray  shading  indicates  elements  in  the  table  that  are  different  from  the  previous  option. 

Table  16.  Option  4  -  PAWSS  Phase  II  transmit  model,  applications  and  locations. 


Process 

Application 

Location 

FF/QM 

RDC  applications 

VTS 

ARI 

PAWSS 

VTS 

VDL  Monitoring 

RDC  application 

VTS 

Display  of  binary  messages 

PAWSS 

VTS 

Message  Creation 

PAWSS 

VTS 

The  cost  summary  is  listed  in  Table  17.  The  rationale  for  each  cost  category  follows. 
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4.4.1  Initial  Transition  /  Installation  Costs 

Hardware:  For  this  option  only  a  server  computer  is  needed  (used  for  the  back-end  applications);  all  user 
interface  (message  creation  and  display)  are  done  within  the  existing  PAWSS  software  and  hardware.  This 
is  needed  for  each  site. 

Network:  One  network  line  is  needed  for  the  VTS  center  (since  PAWSS  handles  the  connections  to  the  AIS 
base  stations,  existing  CGDN+  links  can  be  used).  This  includes  the  initial  installation  cost  and  the  recurring 
cost  for  5  years.  This  is  needed  for  each  site. 

RDC  Software  Development:  This  cost  is  estimated  at  320  hours  of  development  time  to  make  the  RDC 
software  applications  operationally  ready.  This  is  a  one-time  cost  for  the  entire  group  of  VTSs. 

RDC  Software  Documentation:  This  cost  is  estimated  at  80  hours  of  development  time  to  fully  document 
the  RDC  software  applications  operationally  and  create  user  manuals.  This  is  a  one-time  cost  for  the  entire 
group  of  VTSs. 

PAWSS  Software  Development  and  Documentation:  PAWSS  software  development  must  be  done  to 
implement  the  message  creation  and  display  capability.  An  estimate  of  $220K  was  received  from  C2CEN 
(based  on  a  level  of  effort  estimate  by  Lockheed  Martin).  This  estimate  appears  to  be  low  based  on  the 
amount  of  effort  expended  by  Volpe  Center  to  implement  the  same  capability  in  TV32  (government 
research  software).  Our  estimate  was  for  400  man-days  of  effort;  however  we  have  used  the  C2CEN  cost 
estimate  in  the  table. 

Installation  of  RDC  Hardware  and  Software:  This  is  the  cost  to  install  the  computers  listed  under 
hardware  and  software  applications  at  each  site.  This  cost  is  estimated  at  1  week  (40  hours)  to  prepare  the 
hardware  and  software  configuration  for  each  site  and  then  another  week  (40  hours)  for  the  installation  at 
each  site.  In  addition,  16  hours  is  estimated  to  arrange  the  details  of  the  network  line.  Site  survey  costs  are 
assumed  to  be  performed  by  existing  on-site  personnel  and  are  addressed  under  the  personnel  section. 
PAWSS  software  installation  is  covered  under  the  existing  software  upgrade  and  maintenance  contract  so 
there  are  no  costs  for  this.  This  is  needed  for  each  site. 

4.4.2  Training  Costs 

Training  on  Non-PAWSS  Software:  This  is  the  time  required  to  conduct  training  with  the  users  on  the 
non-PAWSS  software  applications.  This  is  estimated  at  2  days  (16  hours).  This  is  needed  for  each  site. 

Training  Development  for  Non-PAWSS  Software:  This  is  the  time  required  to  develop  the  training 
materials  for  the  non-PAWSS  software  applications.  This  is  estimated  at  80  hours  of  development  time. 

This  is  a  one-time  cost  for  the  entire  group  of  VTSs. 

Training  on  PAWSS  Software:  This  is  the  time  required  to  conduct  training  with  the  users  on  the  new 
PAWSS  capability.  This  is  estimated  at  2  days  (16  hours).  This  is  needed  for  each  site. 

Training  Development  for  PAWSS  Software:  This  is  the  time  required  to  develop  the  training  materials 
for  the  enhanced  PAWSS  capabilities.  This  is  estimated  at  80  hours  of  development  time.  This  is  a  one-time 
cost  for  the  entire  group  of  VTSs. 
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4.4.3  Maintenance  Costs 

Monitoring  Processes:  This  cost  is  assumed  to  be  performed  by  existing  on-site  personnel  and  is  addressed 
under  the  personnel  section  in  Appendix  B. 

Initial  Response:  This  cost  is  assumed  to  be  performed  by  existing  on-site  personnel  and  is  addressed  under 
the  personnel  section  in  Appendix  B. 

Second  Level  Response:  This  is  the  time  required  for  someone  to  take  corrective  action  for  system  failures 
of  all  non-PAWSS  software.  This  is  assumed  to  be  able  to  be  done  remotely  (no  travel  required).  T  his  is 
estimated  to  require  4  hours  per  outage,  with  outages  estimated  to  occur  3  times  per  computer  per  year.  The 
estimate  is  $0  for  corrective  action  for  the  PAWSS  software  because  it  is  covered  under  the  existing 
maintenance  contract.  This  is  needed  for  each  site. 

Hardware  Maintenance:  This  is  assumed  to  be  covered  under  manufacturer's  warranty  so  there  are  no 
costs  estimated  for  this. 

Software  Maintenance:  It  is  assumed  that  PAWSS  maintenance  is  already  covered  under  the  existing 
contract.  The  cost  for  five  years  of  maintenance  on  the  non-PAWSS  software  is  estimated  at  20%/year  for  5 
years  of  the  development  cost. 


Table  17.  Option  4  -  PAWSS  Phase  II  transmit  model,  summary  costs. 


Cost  Category 

Per  Site  Costs 
(5yrs) 

Fixed/One  Time  Initial 
Cost 

Initial  Transition  / 
Installation  Costs 

Hardware 

$2,000 

$0 

Network 

$6,250 

$0 

RDC  software  Development 

$0 

$48,000 

RDC  software  Documentation 

$0 

$12,000 

PAWSS  Software  development  &  documentation 

$220,000 

Installation  of  RDC  h/w  and  s/w:  site  survey 

$0 

$0 

Prep  site  specific  details  for  installation 

$6,000 

$0 

Arrange  network  lines 

$2,400 

$0 

Onsite  for  installation 

$6,000 

$0 

Training 

Costs 

Training  -  on  non  PAWSS  s/w 

$2,400 

$0 

Training  Development  -  on  non  PAWSS  s/w 

$0 

$12,000 

Training  Certification 

$0 

$0 

Training  -  on  PAWSS  s/w 

$2,400 

$0 

Training  Development  -  on  PAWSS  s/w 

$0 

$12,000 

Maintenance 

Costs 

Monitoring  processes  -  non-PAWSS  s/w 

$0 

$0 

Initial  Response  at  VTS  -  for  non-PAWSS  s/w 

$0 

$0 

2nd  Level  Response  at  VTS  -  for  non-PAWSS  s/w 

$9,000 

$0 

Hardware  Maintenance 

$0 

$0 

Software  Maintenance  -  non  PAWSS 

$48,000 
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4.4.4  Cost  Totals 

Using  the  costs  in  Table  17  the  total  cost  per  site  (for  five  years)  and  the  total  fixed  (system-wide)  cost  can 
be  totaled.  The  total  cost  is  calculated  as  follows:  9  times  the  total  PAWSS  ports  per-site  costs  plus  3  times 
the  total  non-PAWSS  ports  per-site  costs  plus  the  total  fixed  cost.  These  totals  are  shown  in  Table  18.  The 
additional  option  shown  in  this  table  is  the  CGDN+  option.  For  this  option  the  non-PAWSS  applications  are 
certified  for  use  on  the  CGDN+  (which  is  a  one-time  cost).  This  allows  CGDN+  network  connections  to  be 
used  so  all  of  the  network  costs  can  be  subtracted  out  yielding  a  new  (lower)  total  cost. 


Table  18.  Option  4  -  PAWSS  Phase  II  transmit  model,  cost  totals. 


Per-site  Costs 
for  PAWSS 
Ports  (9) 

Per-site  Costs 
for  Non-PAWSS 
Ports  (3) 

Fixed  Cost  for 
Entire  System 

Total  Cost  for 
All  Sites  for  5 
Years 

Implement  Option  4  at  12  Sites 

$35,250 

$78,650 

$352,000 

$905,200 

With  CGDN+  Certification  Sub-option 

$26,600 

$35,400 

$427,000 

$772,600 

4.5  Option  5  -  PAWSS  Phase  III  Transmit  Model 

Option  5  moves  all  of  the  processes  into  PAWSS  -  message  creation  and  display,  as  well  as  the  back-end 
processes.  The  applications  used  for  the  major  processes  and  the  locations  of  the  computers  running  those 
processes  are  listed  in  Table  19;  the  gray  shading  indicates  elements  in  the  table  that  are  different  from  the 
previous  option.  This  is  done  at  9  of  the  sites;  the  three  non-PAWSS  sites  (Tampa,  LA/LB,  and  Louisville) 
are  transitioned  according  to  Option  2. 

Table  19.  Option  5  -  PAWSS  Phase  III  transmit  model,  applications  and  locations. 


Process 

Application 

Location 

FF/QM 

PAWSS 

VTS 

ARI 

PAWSS 

VTS 

VDL  Monitoring 

PAWSS 

VTS 

Display  of  binary  messages 

PAWSS 

VTS 

Message  Creation 

PAWSS 

VTS 

The  cost  summary  is  listed  in  Table  20.  The  rationale  for  each  cost  category  follows.  All  costs  are  for  the 
PAWSS  ports.  Since  the  three  non-PAWSS  ports  use  the  Tampa  model,  the  per-site  costs  for  those  two 
ports  are  as  shown  under  Option  2.  However,  fixed  (system- wide)  costs  are  included  for  all  12  ports. 

4.5.1  Initial  Transition  /  Installation  Costs 

Hardw  are:  For  this  option  no  additional  computers  are  needed  as  all  added  capability  is  handled  within  the 
existing  PAWSS  software  and  hardware. 

Network:  No  additional  network  lines  are  needed  as  existing  connections  to  PAWSS  are  used. 

RDC  Software  Development:  This  cost  is  estimated  at  320  hours  of  development  time  to  make  the  RDC 
software  applications  operationally  ready.  The  RDC  software  is  still  needed  for  the  2  non-PAWSS  ports  so 
this  development  is  still  required.  This  is  a  one-time  cost  for  the  entire  group  of  VTSs. 
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RDC  Softw  are  Documentation:  This  cost  is  estimated  at  80  hours  of  development  time  to  fully  document 
the  RDC  software  applications  operationally  and  create  user  manuals.  This  is  a  one-time  cost  for  the  entire 
group  of  VTSs. 

PAWSS  Software  Development  and  Documentation:  Extensive  software  development  must  he  done  to 
implement  the  message  creation  and  display  capability  and  to  incorporate  all  of  the  back-end  processes 
(FF/QM)  into  PAWSS.  This  is  estimated  at  1040  man-days  of  effort. 

Installation  of  RDC  Hardware  and  Software:  Since  existing  PAWSS  hardware  is  being  used  and  all 
software  upgrade  costs  are  covered  under  the  existing  contract,  there  are  minimal  costs  for  installation.  The 
only  cost  estimated  is  1  week  (40  hours)  for  the  installation  at  each  site  to  do  site  configuration  of  the  back¬ 
end  processes.  This  is  needed  for  each  site. 

4.5.2  Training  Costs 

Training  on  Non-PAWSS  Software:  All  capability  is  in  PAWSS  for  the  9  PAWSS  ports  so  no  cost  for 
this. 

Training  Development  for  Non-PAWSS  Software:  This  is  the  time  required  to  develop  the  training 
materials  for  the  non-PAWSS  software  applications.  This  is  estimated  at  80  hours  of  development  time. 

This  is  required  since  the  RDC  software  is  used  in  the  3  non-PAWSS  ports.  This  is  a  one-time  cost  for  the 
entire  group  of  VTSs. 

Training  on  PAWSS  Software:  This  is  the  time  required  to  conduct  training  with  the  users  on  the  newr 
PAWSS  capability.  This  is  estimated  at  2  days  (16  hours).  This  is  needed  for  each  site. 

Training  Development  for  PAWSS  Software:  This  is  the  time  required  to  develop  the  training  materials 
for  the  enhanced  PAWSS  capabilities.  This  is  estimated  at  80  hours  of  development  time.  This  is  a  one-time 
cost  for  the  entire  group  of  VTSs. 

4.5.3  Maintenance  Costs 

Monitoring  Processes:  This  cost  is  assumed  to  be  performed  by  existing  on-site  personnel  and  is  addressed 
under  the  personnel  section  in  Appendix  B. 

Initial  Response:  This  cost  is  assumed  to  be  performed  by  existing  on-site  personnel  and  is  addressed  under 
the  personnel  section  in  Appendix  B. 

Second  Level  Response:  This  is  the  time  required  for  someone  to  take  corrective  action  for  system  failures 
of  all  non-PAWSS  software.  This  is  assumed  to  be  able  to  be  done  remotely  (no  travel  required).  This  is 
estimated  to  require  4  hours  per  outage,  with  outages  estimated  to  occur  3  times  per  computer  per  year.  The 
estimate  is  $0  for  corrective  action  for  the  PAWSS  software  because  it  is  covered  under  the  existing 
maintenance  contract.  This  is  needed  for  each  site. 

Hardware  Maintenance:  This  is  assumed  to  be  covered  under  manufacturer’s  warranty  so  there  are  no 
costs  estimated  for  this. 
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Software  Maintenance:  It  is  assumed  that  PAWSS  maintenance  is  already  covered  under  the  existing 
contract.  The  cost  for  five  years  of  maintenance  on  the  non-PAWSS  software  is  estimated  at  20%/year  for  5 
years  of  the  development  cost. 


Table  20.  Option  5  -  PAWSS  Phase  III  transmit  model,  summary  costs. 


Cost  Category 

Per  Site  Costs 
(5yrs) 

Fixed/One  Time  Initial 
Cost 

Initial  Transition  / 
Installation  Costs 

Hardware 

$0 

$0 

Network 

$0 

$0 

RDC  software  Development 

$0 

$48,000 

RDC  software  Documentation 

$0 

$12,000 

PAWSS  Software  development  &  documentation 

$1,248,000 

Installation  of  RDC  h/w  and  s/w:  site  survey 

$0 

J$o 

Prep  site  specific  details  for  installation 

$0 

$0 

Arrange  network  lines 

$0 

$0 

Onsite  for  installation 

$6,000 

$0 

Training 

Costs 

Training  -  on  non  PAWSS  s/w 

$0 

$0 

Training  Development  -  on  non  PAWSS  s/w 

$0 

$12,000 

Training  Certification 

$0 

$0 

Training  -  on  PAWSS  s/w 

$2,400 

$0 

Training  Development  -  on  PAWSS  s/w 

$0 

$12,000 

Maintenance 

Costs 

Monitoring  processes  -  non-PAWSS  s/w 

$0 

$0 

Initial  Response  at  VTS  -  for  non-PAWSS  s/w 

$0 

$0 

2nd  Level  Response  at  VTS  -  for  non-PAWSS  s/w 

$0 

$0 

Hardware  Maintenance 

$0 

$0 

Software  Maintenance  -  non  PAWSS 

$48,000 

4.5.4  Cost  Totals 

Using  the  costs  in  Table  20  the  total  cost  per  site  (for  five  years)  and  the  total  fixed  (system-wide)  cost  can 
be  totaled.  The  same  as  in  options  3  and  4,  the  total  cost  is  calculated  by  multiplying  the  total  PAWSS  per- 
site  costs  by  9,  adding  in  3  times  the  total  per-site  costs  of  Option  2,  and  then  adding  the  total  fixed  cost. 
These  totals  are  shown  in  Table  21 .  The  additional  option  shown  in  this  table  is  the  CGDN+  option.  For  this 
option  the  non-PAWSS  applications  are  certified  for  use  on  the  CGDN+  (which  is  a  one-time  cost).  This 
allows  CGDN+  network  connections  to  be  used  so  all  of  the  network  costs  can  be  subtracted  out  yielding  a 
new  (lower)  total  cost. 
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Table  21 .  Option  5  -  PAWSS  Phase  111  transmit  model,  cost  totals. 


Per-site  Costs 
for  PAWSS 
Ports  (9) 

Per-site  Costs 
for  Non-PAWSS 
Ports  (3) 

Fixed  Cost 
for  Entire 
System 

Total  Cost  for 
All  Sites  for  5 
years 

PAWSS  Phase  III  Transmit  Model  Option  - 
12  Sites 

$8,400 

$78,650 

$1,380,000 

$1,691,550 

With  CGDN+  Certification  Sub-option 

$8,400 

$35,400 

$1,455,000 

$1,636,800 

5  TRANSITION  OF  DEMONSTRATION  AREAS  TO  OTHER  GOVERNMENT 
AGENCY  RESPONSIBILITY 

5.1  Stellwagen  Bank  Transition  to  NOAA 

NOAA  has  agreed  to  take  over  operation  of  the  Stellwagen  Bank  AIS  Transmit  operations.  This  will  involve 
transferring  some  processes  and  monitoring  responsibility  from  Alion  (RDC)  to  Comell/UNH  (NOAA).  The 
Queue  Manager  process  will  be  moved  to  Cornell  and  be  monitored  along  with  the  Fetcher/Formatter  that  is 
already  there.  The  AIS  Radio  Interface  (ARI)  is  running  on  the  personal  computer  (PC)  at  Provincetown. 
This  will  remain  the  same;  however,  monitoring  responsibility  will  shift  from  Alion  (RDC)  to  UNH 
(NOAA).  The  current  AIS  Class  A  radio  will  be  replaced  with  an  AIS  AtoN  transmitter  by  UNH.  NOAA 
(Dave  Wiley)  has  requested  the  frequency  authorizations  for  this  transition.  One  additional  step  that  must  be 
performed  by  UNH  prior  to  transition,  is  the  FF  must  be  updated  to  generate  the  correct  Area  Notice 
Message  format  as  per  the  RTCM  standard.  The  transition  steps  and  tentative  timeline  are  contained  in 
Table  22. 


Table  22.  Stellwagen  Bank  transition  steps. 


Task 

Tentative 

Date 

Convert  Cornell  FF  to  RTCM  compliant  message 

June  2010 

Set  up  QM  at  Cornell,  test,  and  then  transition  operations  from  RDC  to  Cornell 

July  2010 

Purchase  AIS  AtoN  unit  and  install  at  Provincetown.  Set  up.  configure,  and  test  Cutover  operations 
from  Class  A  unit  to  AIS  AtoN  unit 

July  2010 

Handoff  complete 

August  2010 

Most  of  this  tasking  is  the  responsibility  of  UNH  (NOAA).  Alion  (RDC)  will  provide  technical  assistance  as 
needed,  but  this  should  be  minimal  and  can  be  covered  under  the  current  contract. 

The  Stellwagen  Bank  site  is  a  great  model  for  how  AIS  transmit  capability  can  be  implemented  for  other 
agencies  that  have  transmit  needs  that  the  Coast  Guard  cannot  meet. 

5.2  Columbia  River  Transition  to  Volpe/COLRIP 

The  Volpe  Center  will  take  over  the  AIS  Transmit  operations  in  the  Columbia  River  as  part  of  their 
contracted  support  to  the  Columbia  River  Pilots  (COLRIP).  This  will  involve  transferring  some  processes 
and  monitoring  responsibility  from  Alion  (RDC)  to  Volpe  (COLRIP).  The  FF,  QM,  and  ARI  processes  will 
be  moved  to  the  COLRIP  office  and  be  monitored  by  Volpe  along  with  the  TV32  installation  that  is  there 
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now.  COLRIP  and  Volpe  will  monitor  system  performance  and  VDL  loading  using  data  feeds  from  the  two 
transmitter  sites.  The  transition  steps  and  tentative  timeline  are  contained  in  Table  23. 


Table  23.  Columbia  River  transition  steps. 


Task 

Tentative  date 

Set  up  FF,  QM,  and  ARI  at  COLRIP,  test,  and  then  transition  operations  from  Alion  to  Volpe 

July  2010 

Handoff  complete 

August  2010 

Most  of  this  tasking  is  the  responsibility  of  Volpe  (COLRIP).  Alion  (RDC)  will  provide  technical  assistance 
as  needed,  but  this  should  be  minimal  and  can  be  covered  under  the  current  contract. 

6  OTHER  CONSIDERATIONS 
6.1  User  Software 

All  of  the  implementation  plans  described  above  are  only  for  the  shore-side  infrastructure.  In  order  for  users 
to  receive  and  display  the  binary  messages  they  must  have  software  that  implements  the  new  RTCM  Binary 
Message  standard. 

One  of  the  original  project  goals  was  to  get  commercial  vendors  to  implement  the  support  for  the  new 
messages  within  their  ECS  packages.  Unfortunately,  this  has  not  yet  happened.  To  date  there  are  no 
commercial  software  packages  that  implement  the  entire  standard.  ARINC’s  PilotMate  software  used  in 
Tampa  and  LA/LB  supports  the  Environmental  Message  specification  but  not  the  others.  The  Environmental 
Message  decode  and  display  capability  was  added  specifically  to  support  the  Tampa  Bay  Pilots.  Since  the 
Tampa  Bay  Pilots  are  not  interested  or  able  to  fund  further  development  ARINC  has  no  plans  to  further 
implement  binary  message  decodes.  There  are  also  several  other  commercial  companies  who  have 
participated  in  the  RTCM  Working  Group  and  have  claimed  to  be  in  the  process  of  implementing  support 
(ICAN  and  Transas)  though  this  capability  has  not  been  verified  to  date.  Another  company  (Rose  Point)  has 
also  recently  claimed  to  have  implemented  the  Area  Notice  and  Environmental  Messages  but  again  this  has 
not  been  verified  to  date. 

In  order  to  enable  the  research  and  proof  of  concept  development  to  continue  in  the  absence  of  commercial 
ECS  packages  for  binary  message  decoding,  a  set  of  government  applications  has  been  developed.  Alion 
developed  a  simple  EM  Decoder  that  does  a  complete  decode  and  text  display  of  the  EM  data.  This 
application  can  run  in  a  pass-thru  mode  allowing  it  to  run  in  parallel  with  other  software  that  wants  to  use 
the  AIS  data  stream  -  whether  it  originates  from  a  serial  or  network  connection.  The  other  main  software 
package  is  TransView,  or  TV32,  which  is  GIS  software  package  developed  and  implemented  by  the  Volpe 
Center  to  provide  real-time  display  of  vessel  tracking  and  navigation  information.  TV32  provides  full- 
featured  decoding  and  display  of  AIS  Environmental,  Waterways  Management  and  Area  Notice  Messages. 
The  Environmental  Messages  are  shown  in  pop-up  boxes  on  the  chart  at  the  appropriate  geographic 
location.  Area  Notice  Messages  are  plotted  as  overlays  on  the  chart.  Waterways  Management  Messages  are 
shown  in  separate  dialog  boxes.  In  addition  to  display,  TV32  also  supports  the  creation  of  Area  Notice  and 
Waterway  s  Management  Messages  using  graphical  chart  tools. 
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6.2  AIS  Training  Certification  and  Watchstander  Qualification  Process 

Currently,  all  potential  VTS  watchstanders  must  attend  the  Vessel  Traffic  System  (VI  S)  Watchstander 
Training  Lab  that  is  located  in  Baltimore,  MD.  The  training  is  conducted  at  the  Maritime  Institute  of 
Technology  and  Graduate  Studies  (MITAGS).  The  Institute  has  been  providing  high-quality  maritime 
training  programs  for  military  and  commercial  mariners  for  over  thirty  years.  The  Electronic  Navigation  and 
Vessel  Traffic  Systems  MITAGS'  programs  cover  the  “best  practices”  in  the  operation  of  electronic 
navigation  equipment1.  T  he  Institute's  courses  range  from  the  basic,  such  as  Radar,  to  the  advanced,  such  as 
Integrated  Bridge  Systems  (IBS)  and  Vessel  Traffic  Systems  (VTS).  This  is  the  only  certified  training 
facility  in  the  United  States  to  be  designated  as  a  National  Vessel  Traffic  Operator  Training  Center. 

According  to  Mr.  Eric  Friend  who  is  the  director  of  training  at  MITAG,  the  addition  of  AIS  transmit 
capability  will  have  minimal  impact  on  their  training  curriculum.  Mr.  Friend  stated  that  the  updating  of  any 
course  materials  could  be  done  quickly,  therefore  the  costs  would  be  insubstantial.  MITAG  uses  Transas 
Navi-Trainer  for  their  training  simulator.  Currently  the  Transas  software  has  the  ability  to  perform  AIS 
transmit  functions.  It  is  Mr.  Friend's  opinion  that  there  will  be  virtually  no  impact  with  regards  to  the 
simulator  training  that  students  receive  with  regards  to  cost. 

After  two  weeks  the  students  leave  the  training  facility  trained  but  not  qualified.  The  qualification  process 
takes  place  at  each  individual  VTS  under  the  supervision  of  the  VTS  supervisor  and  qualified  watch 
standers.  The  qualification  standards  at  each  VTS  will  have  to  be  updated  to  reflect  the  AIS  transmit 
capability.  According  to  Mr.  Bruce  Riley  (USCG  Vessel  Traffic  Services  Training,  Operations  and 
Personnel  Resource  Manager),  the  addition  of  AIS  transmit  capability  w  ill  have  minimal  impact  on  the 
qualification  process  of  watchstanders  or/and  supervisors.  How  much  the  qualification  process  will  have  to 
change  will  depend  on  which  alternative  is  chosen.  Regardless  of  the  chosen  option,  it  is  of  his  opinion  that 
the  cost  impact  is  minimal. 

If  the  all  PAWSS  alternative  is  chosen  (Option  5)  then  Lockheed  Martin  will  implement  any  support 
training  required  for  its  support  personnel.  If  the  alternative  chosen  has  a  combination  of  Lockheed  Martin 
software  and  other  software  such  as  Alion,  then  the  appropriate  training  will  have  to  be  conducted  by  the 
chosen  developer. 

Overall,  the  impact  of  training  and  qualification  is  considered  to  be  minimal.  Any  amount  of  time  devoted 
by  technical  writers  or  training  staff  is  below  the  threshold  encompassed  in  this  report.  Therefore,  while  it  is 
being  discussed  in  this  section  there  will  not  be  a  line  item  in  the  cost  section  accounting  for  training  and 
qualification  adjustments. 

6.3  Doctrine 

AIS  Binary  Broadcast  provides  a  new  way  of  communication  between  VTS  personnel  and  the  ships.  As 
more  shipboard  ECSs  gain  ability  to  decode  AIS  Binary  messages,  electronic  form  of  communication  is 
expected  to  displace  voice  over  VHF.  This  process  will  be  gradual  due  to  a  wide  range  of  equipment  already 
deployed  and  in  use.  So,  all  forms  of  communication  will  need  to  run  in  parallel  for  foreseeable  future. 
While  legacy  forms  of  communication  will  have  to  remain  in  place,  many  benefits  of  AIS  Binary  Broadcast 
will  be  realizable  immediately,  such  as  providing  increase  in  clarity  of  communication  and  situational 


1  Detailed  information  about  the  course  can  be  found  at  httn://www.mitags.org/t-electronicnavigation.asn\. 
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awareness.  The  following  paragraphs  outline  how  each  type  of  AIS  Broadcast  impacts  VTS  operation  and 
what  support  is  required  from  VTS  personnel. 

AIS  Environmental  Messages  are  provided  as  Met-Hydro  information  service  to  mariners,  complimentary  to 
voice  weather  updates  broadcast  over  VHF.  AIS  environmental  updates  are  transmitted  every  3-6  minutes. 
The  process  of  formatting,  processing  and  transmitting  these  messages  is  fully  automated.  AIS 
Environmental  Messages  transmit  relies  on  availability  of  internet  connection  to  NOAA  PORTS  Web 
Services  for  fetching  of  environmental  data,  and  connection  to  the  radio  through  PAWSS  or  AIS  Radio 
Interface.  Designated  personnel  should  periodically  check  execution  of  Fetcher/Formatter  and  Queue 
Manager,  and  AIS  Radio  Interface  processes  using  AIS  Binary  Transmit  Monitoring  Dashboard  for 
abnormal  operation  and  errors.  Recommended  check-up  interval  is  once  every  hour,  around  the  clock.  There 
is  no  operator  involvement  required  for  normal  operation  beyond  periodic  monitoring,  but  operator  might 
have  to  do  some  initial  troubleshooting  in  case  of  malfunction.  Details  on  monitoring  procedures  and 
problems  resolution  will  be  provided  in  AIS  Binary  Transmit  Monitoring  Dashboard  operating  manual. 

AIS  Waterways  Management  Messages  provide  ship  traffic  management  tools  that  are  supplementary  to 
voice  over  VHF  communication  between  ships  and  VTS  operators.  As  decoding  of  WMMs  by  ship  ECSs 
become  commonplace,  WMMs  will  allow  significant  reduction  in  voice  traffic.  Adoption  of  WMMs  is 
expected  to  significantly  reduce  workload  of  VTS  operators,  and  improve  clarity  of  communication. 
Currently  decoding  of  WMMs  by  ECSs  is  not  mandatory  therefore,  it’s  recommended  that  VTS  operators 
start  utilizing  WMM,  and  continue  to  use  voice  communication  for  confirmation  of  reception  of  WMMs. 
Several  software  packages  are  available  for  creation  of  WMM  Messages,  such  as  TV32  and  VTS  Info 
Manager.  Watchstander  should  create  WMMs  and  add  them  to  transmit  queue  at  the  same  time  as  this 
traffic  management  information  is  made  available  to  ships  via  other  means  of  communication.  Watch 
stander  should  continuously  check,  that  WMMs  being  transmitted  via  AIS  reflect  what  is  being  relayed  to 
ships  via  other  means  of  communication.  Transmit  of  WMMs  is  being  carried  out  via  same  mechanism  as 
Environmental  Messages,  so  monitoring  Environmental  Messages  transmit  also  ensures  WMMs  transmit. 

AIS  Area  Notice  Messages  allow  VTS  and  other  authorized  agencies  to  create  security  zones,  speed  zones, 
and  other  areas  with  specific  restrictions  and  alerts.  Currently,  those  Area  Notices  are  posted  as  Notices  to 
Mariners  and  made  available  via  the  Internet  and  VHF  Voice  Broadcast.  AIS  area  notices  will  provide  a 
new  method  for  ships  to  receive  this  information,  with  added  benefit  that  the  zones  will  be  automatically 
overlaid  on  ships  chart-plotter  display.  Transmit  of  WMMs  is  being  carried  out  via  the  same  mechanism  as 
Environmental  Messages,  so  monitoring  Environmental  Messages  transmit  also  ensures  area  notice  message 
transmit.  Basic  monitoring  of  transmit  functionality  outlined  under  Environmental  Messages  monitoring 
ensures  that  messages  are  being  sent  out,  but  not  the  contents  of  the  messages.  Watchstander  should  check 
every  hour,  around  the  clock  that  Area  Notice  Messages  are  being  sent  out  and  properly  reflects  what  is 
being  broadcast  via  other  means  of  communication,  and  accordingly  modify  the  transmit  queue  by 
adding/deleting  and  modifying  those  area  notice  messages. 
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7  RECOMMENDATIONS 
7.1  Least  Expensive  Option 

The  total  costs  for  each  of  the  5  options  are  repeated  again  in  Table  24.  Using  the  cost  model  and 
assumptions  described  in  Appendix  B,  the  lowest  cost  option  that  would  provide  the  enhanced  capability  at 
all  12  VTS  locations  is  Option  2  with  CGDN+  certification  for  the  non-PAWSS  applications.  Option  3  with 
CGDN+  certification  is  only  slightly  more  expensive  and  makes  use  of  the  development  costs  already  spent 
on  the  PAWSS  Phase  I  interface.  However,  neither  of  these  is  the  recommended  option. 


Table  24.  Summary  of  total  costs. 


Option  # 

1 

2 

3 

4 

5 

Description 

RDC-Hosted 
PAWSS  Phase  1 

Operational 

Without 

PAWSS 

PAWSS  Phase 

1  Transmit 

PAWSS  Phase 

II  Transmit 

PAWSS  Phase 

III  Transmit 

Total  cost  for  all  12 
sites  for  5  years 

$1,251,150 

$1,063,800 

$766,200 

$905,200 

$1  691,550 

With  CGDN+ 
Certification  Sub-option 

$1,118,550 

$619,800 

$633,600 

$772,600 

$1,636,800 

Just  maintain  Tampa 
and  Port  Arthur  sites. 

$273,075 

N/A 

$192,850 

N/A 

N/A 

7.2  Recommended  VTS  Option 

The  recommended  VI  S  option  is  a  complex  choice  if  more  than  just  cost  is  taken  into  account.  As  w  ill  be 
discussed  in  more  depth  in  the  following  sections,  it  is  recommended  to  keep  the  back-end  processes 
separate  from  the  display  process.  This  would  eliminate  Option  5  (which  is  also  the  highest  cost  option). 
From  a  watchstander  perspective  it  would  be  best  if  all  operations  were  possible  from  a  single  G1S  display 
and  not  have  two  different  systems;  each  providing  an  incomplete  but  overlapping  set  of  capability.  A  single 
system  would  also  be  easier  and  cheaper  for  maintenance,  training,  and  watchstander  qualification.  Thus  the 
recommended  option  is  Option  4,  which  consolidates  AIS  binary  message  creation  and  display  capability 
into  the  existing  operational  GIS  (PAWSS).  This  option  is  higher  cost  than  Options  2  and  3;  however,  much 
of  that  cost  is  the  upgrade  to  the  PAWSS  software,  a  one  time  cost. 

Another  consideration  is  how  the  VTS  display  system  will  integrate  with  the  Interagency  Operation  Center 
(IOC)  project.  IOC  Segment  2  will  provide  a  new  Sensor  Management  System  (SMS)  to  each  of  the 
Sectors.  The  architecture  envisioned  for  this  SMS  is  based  on  a  Service  Oriented  Architecture  (SOA)  and 
features  shared  sensors  (radars,  cameras,  etc)  at  the  Sectors  with  VTSs  and  support  for  different  display 
systems  for  different  sets  of  users. 

Although  the  VTS  display  system  could  be  entirely  different  from  the  IOC  display  system  it  might  make 
sense  if  they  were  similar.  Currently  the  display  requirements  of  the  IOC  and  those  of  a  VTS  have  many 
similarities.  The  key  differences  in  these  requirements  hinge  on  the  fact  that  the  IOC  focuses  on  security  and 
the  VTS  is  focused  on  safety  and  traffic  management.  Currently  a  unique  window  exists  since  IOC  Segment 
2  is  in  its  early  stages  of  development  at  the  same  time  AIS  transmission  capabilities  are  being  transitioned 
from  a  test  bed  to  an  operational  status.  A  display  system  could  be  developed  that  would  support  both  sets  of 
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requirements  so  that  one  system  could  be  deployed  (perhaps  with  different  modules  or  user  configurations) 
which  would  make  training,  maintenance,  and  support  more  economical. 

In  addition  to  the  IOC  integration,  there  are  other  big-picture  issues  such  as  Nationwide  AIS  (NAIS) 
integration  that  need  to  be  resolved  longer  term.  However,  it  is  recommended  to  go  forward  in  the  short 
term  with  Option  4  while  concurrently  conducting  a  study  on  how  to  resolve  the  long-term  issues.  This  will 
get  a  valuable  service  out  into  the  field  for  use  very  quickly  instead  of  waiting  for  years  for  all  of  the  issues 
to  be  resolved.  Also,  in  order  to  make  the  transition  easier  it  is  recommended  to  start  transmitting  just  the 
Environmental  message  using  the  PORI'S  data.  This  requires  no  operator  interaction  for  message  creation 
and  thus  minimizes  the  impact  to  the  VTS  while  the  enhanced  capability  is  being  rolled  out.  Once  the 
systems  are  in  place  and  working  well.  Area  Notice  and  Waterways  Management  messages  could  be  added 
in.  This  would  just  be  a  change  to  the  operational  procedures,  as  all  hardware/software  necessary  to  do  this 
would  have  been  put  into  place  in  the  initial  installation. 

7.3  Recommendation  for  Coast  Guard  Vessel  Participation 

I  he  Coast  Guard  standard  for  shipboard  ECS  software  is  in  a  period  of  transition.  Currently  Coast  Guard 
cutters  use  a  variety  of  software;  e.g.  Transas  NaviSailor  and  The  Cap’n.  C2CEN  recently  completed  and  is 
starting  to  push  out  to  the  fleet  the  internally  developed  VEGA  software.  This  past  fall,  C2CEN  awarded  the 
contract  for  the  future  shipboard  ECS  systems  to  Sperry.  At  this  present  time,  NONE  of  these  systems 
support  enhanced  AIS  capabilities.  Currently  the  only  chart  navigation  software  available  which  fully 
utilizes  the  AIS  transmit  capability  is  Transview  (TV32)  which  is  maintained  and  developed  by  the  Volpe 
National  Transportation  Systems  Center  (VOLPE).  Volpe  developed  these  advanced  navigation  features 
while  working  closely  with  the  Coast  Guard  R&D  center  during  the  last  two  years.  During  the  course  of 
this  project,  Volpe  implemented  changes  in  the  software  that  take  full  advantage  of  this  added  capability. 
This  software  has  been  given  to  several  USCG  cutters  and  shore  locations  for  test  purposes. 

We  strongly  recommend  that  CG-761  and  CG-762  work  closely  with  C2CEN  with  regards  to  the  integration 
of  AIS  transmit  capabilities  into  the  USCG's  ECS  software.  If  these  added  capabilities  were  developed  into 
Sperry's  navigation  software,  when  Sperry's  navigation  software  becomes  the  standard  for  Coast  Guard 
cutters  and  small  boats  the  Coast  Guard  personnel  onboard  would  be  able  to  take  advantage  immediately  of 
the  added  capabilities.  The  changes  required  in  the  software  are  not  extensive  and  a  window  of  time  exists 
currently  in  which  the  Coast  Guard  could  take  advantage.  In  the  short  term,  TV32  can  be  used  by  those  units 
that  want  to  take  advantage  of  the  enhanced  capabilities  now. 

7.4  Recommendations  for  software  modularity 

The  R&D  implementation  of  AIS  transmit  is  based  upon  a  modular,  distributed  architecture.  This 
architecture  is  implemented  using  stand-alone  processes  that  are  loosely  coupled  using  TCP/IP  client/server 
interfaces.  All  interfaces  have  been  documented  and  are  defined  using  non-proprietary  technologies.  These 
interfaces  are  not  bound  to  specific  programming  languages  or  development  packages  and  provide  an  open 
environment  for  third-party'  vendors. 

It  is  highly  recommended  to  maintain  this  modularity  as  AIS  transmit  is  being  rolled  out  in  all  VTS  ports. 
Keeping  modularity  goes  along  with  established  best  practices  in  software  development  and  allows 
flexibility  in  configuration  and  usage.  Modularity  allows  different  components  to  be  run  from  different 
physical  locations,  and  allows  authorized  personnel  to  independently  access  appropriate  functionality. 
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instead  of  relying  on  a  single  operator  to  perform  all  functions.  Another  major  benefit  of  software 
modularity  is  that  it  allows  incorporation  of  third-party  software,  and  makes  certain  that  software  upgrades 
can  be  performed  on  a  competitive  basis.  Upgrades  to  individual  modules  can  be  done  independently,  and 
substituted  as  needed.  The  follow  ing  few  paragraphs  will  briefly  define  the  functionality  of  each  module  and 
provide  rational  for  keeping  them  as  stand-alone  applications. 

7.4.1  VTS  Information  Manager  (VIM) 

The  VTS  Information  Manager  has  two  primary  functions.  First,  it  allows  creation  of  AIS  Area  Notice  and 
Waterways  Management  Messages.  In  addition,  it  maintains  the  re-transmit  queue  in  which  messages  are 
kept  for  the  duration  of  time  that  these  messages  are  active.  The  VIM  allows  messages  created  internally  to 
be  added  to  the  broadcast  queue,  and  also  accepts  them  from  other  programs,  such  as  TV32.  Keeping  this 
functionality  in  a  stand-alone  application  allows  authorized  personnel,  other  than  the  VTS  Watchstander,  to 
create  and  broadcast  the  messages.  Currently,  the  VIM  combines  the  functionality  of  creating  messages,  and 
also  maintains  the  message  broadcast  queue.  It  is  recommended  to  separate  these  functions  into  separate 
applications.  In  addition,  an  XML-based  format  should  be  developed  for  storing  and  exchanging  user¬ 
generated  Waterways  Management  and  Area  Notice  messages. 

7.4.2  Fetcher/Formatter  (FF) 

The  Fetcher/Formatter  performs  conversion  of  NOAA  PORTS  data  published  via  Web  Services  into  the 
AIS  binary  format  and  forwards  it  to  the  Queue  Manager  at  pre-set  time  intervals.  It  is  recommended  to 
keep  this  functionality  as  a  stand-alone  process,  as  it  provides  necessary'  flexibility  in  upgrades  as  NOAA 
Web  Services  are  dynamically  evolving  and  new  sensors  and  sites  are  being  added. 

7.4.3  Queue  Manager  (QM) 

The  Queue  Manager  is  a  server  application  that  provides  core  AIS  binary  message  processing  functionality 
by  performing  message  packing,  prioritization,  load  balancing,  and  transmission  to  the  AIS  Radio  Interface. 
It  is  absolutely  essential  that  the  interfaces  by  which  the  QM  accepts  messages  are  kept  open.  Keeping  the 
QM  interface  open  allows  external  applications  to  provide  messages  for  AIS  binary  transmission  and 
ensures  that  the  USCG  is  not  locked  into  a  proprietary  single-vendor  solution. 

7.4.4  AIS  Radio  Interface  (ARI) 

The  AIS  Radio  Interface  provides  the  QM  with  a  pass-through  functionality  to  an  AIS  radio.  Keeping  it  as  a 
standalone  module  allows  flexibility  in  hosting  of  the  QM  application  on  either  an  internal  or  external 
network.  ARI’s  second  function  is  making  accessible  base  stations  that  do  not  have  a  network  interface.  To 
enable  this,  ARI  can  be  run  at  a  remote  location  at  the  base  station,  while  QM  is  running  in  a  central 
location. 

7.5  Recommendations  for  USCG  Enterprise  Architecture 

Enterprise  Architecture  is  a  key  discipline  for  managing  relationships  between  business  practices  and 
technology  in  large-scale  implementations.  The  Clinger-Cohen  Act  of  1996  mandated  that  all  Federal 
Agencies  develop  and  maintain  enterprise  information  technology  (IT)  architectures.  In  response,  the  Chief 
Information  Officers  (CIO)  Council  established  the  Federal  Enterprise  Architecture  Framework  (FEAF). 

The  FEAF  established  a  comprehensive  architectural  guide  to  define  the  business  and  technology 
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framework  for  the  Federal  Government  in  order  to  facilitate  the  shared  development  of  common  processes 
and  information  between  Federal  as  well  as  other  government  agencies.  Semper  Paratus  Enterprise 
Architecture  Realization  (SPEAR)  is  the  CG  specific  implementation  of  FEAF  [6,  7],  The  USCG  Enterprise 
Service  Bus  (ESB)  is  based  on  the  Fiorano  Service  Oriented  Architecture  (SOA)  suit  and  Vordel  XML 
Gateway.  Technical  details  of  SPEAR  are  described  in  SPEAR  Implementation  Guide  [7]. 

The  AIS  transmit  capability  should  be  considered  for  inclusion  in  the  USCG  ESB,  as  the  recently  published 
SPEARS  Implementation  Guide  specifically  states  that  connections  between  Coast  Guard  services  and 
systems  should  use  the  ESB.  The  SPEAR  Guide  also  states  that  the  OSC  Production  Service  Oriented 
Architecture  (PSOA)  and  Emerging  Technologies  (ET)  teams  perform  reviews  of  CG  software  architecture, 
and  any  exception  to  the  ESB  are  allowed  only  after  consulting  with  those  teams. 

The  AIS  transmit  capability  aligns  well  with  the  CG  vision  outlined  in  the  SPEAR  white  paper  [6].  While 
the  ESB  architecture  adds  some  overhead  and  latency  that  affects  high-throughput  and  real-time 
applications,  AIS  transmit  is  both  latency-tolerant  and  low-bandwidth  so  this  is  not  a  concern.  The  Fiorano 
SOA  suite  guidelines  state  that  it  is  most  appropriate  for  messages  that  utilize  XML  to  express  content,  are 
less  than  10MB  per  message,  and  could  work  in  asynchronous  or  pseudo-synchronous  transmission  modes. 
This  aligns  well  with  AIS  binary  messages.  The  benefits  of  including  AIS  transmit  in  SPEAR  would  include 
standardization  of  interfaces,  improved  access  to  the  service,  and  greatly  increased  flexibility  in 
configuration  and  usage.  For  example,  it  would  enable  authorized  personal,  other  than  the  Watchstander  on 
duty,  to  create  Safety  Zones  and  Alerts  and  automatically  synchronize  information  published  on  the  Internet 
with  information  being  broadcast  via  VHF  and  AIS. 

To  allow  inclusion  of  AIS  transmit  in  SPEAR,  all  interfaces  w  ill  need  to  be  brought  into  compliance  with 
the  Fiorano  messaging  standard.  The  R&D  implementation  currently  in  operation  is  utilizing  Extensible 
Markup  Language  (XML)  and  Simple  Object  Access  Protocol  (SOAP)  for  access  to  NOAA  PORTS  Web 
Services.  Internal  communication  in  the  AIS  data  processing  suite  is  done  using  ASCII  plain  text  messaging 
over  TCP/IP.  For  proof  of  concept,  it  was  deemed  not  cost-effective,  nor  suitable  to  use  XML  and  Web 
Services  for  internal  communication  within  the  data  processing  chain.  Web  Services  requires  expensive 
software  licensing  and  labor  for  installation,  configuration,  and  maintenance  and  provides  no  realizable 
benefits  for  one-off  R&D  efforts.  Furthermore,  the  XML  format  is  bulky  and  its  size  overhead  makes  it 
difficult  to  log  and  parse  data,  and  monitor  operations  without  the  use  of  specialized  tools  that  would  have 
to  be  developed  at  an  extra  cost.  However,  upon  transitioning  to  an  operational  system,  the  benefits  of 
aligning  with  SPEAR  outweigh  these  drawbacks. 

Inclusion  of  AIS  transmit  in  the  SPEAR  CG  Enterprise  Architecture  is  a  major  effort.  It  will  requires 
cost/benefit  analysis,  revision  of  current  architecture,  design  of  Fiorano  compliant  interfaces,  incorporation 
of  access  control  mechanisms  to  comply  with  Vordel  and  Fiorano  security  provisions  and  upgrade  to  all 
software  in  the  data  processing  suite  to  handle  messaging  via  JMS  (Java  Messaging  Server).  Detailed 
evaluation  for  including  AIS  transmit  in  SPEAR  is  beyond  the  scope  of  this  transition  plan.  So,  a  reparate 
study  should  be  performed  to  evaluate  the  feasibility  (and  architecture)  and  effectiveness  and  provide 
recommendations  on  implementation. 
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APPENDIX  A.  RDC  AIS  EQUIPMENT  CURRENTLY  DEPLOYED  IN  THE 

FIELD 

A.l  Tampa  Marine  Towing 

Four  Netbooks,  power  supplies,  misc  USB  cables,  and  USB  adapters. 

A.2  Carnival  Cruise  Ship  Inspiration 

Dell  D600  computer,  power  supply,  RS-422  adapter,  and  USB  cable. 

A.3  USCG  Sector  St.  Petersburg 

Windows  XP  tower  with  video  A/B  switch  and  UPS  for  backup  power. 

A.4  VTS  Tampa 

Windows  XP  tower  computer,  LCD  monitor  and  UPS  for  backup  power. 

A.5  CGC  Vise 

TV-32  software,  USB  adapter,  and  cables. 

A.6  CGC  Applebee 

Lenovo  laptop  computer,  power  supply,USB  adapter,  and  cables. 


Acquisition  Directorate 

Research  &  Development  Center 


A-l 


t  tk'la&ifurd  U*. KO<  !  tiunin  ,il  KMK 

Uuhiu  Nkiic’n  :m<» 


Alternatives  Report  for  Transition  of  Prototype  AIS  Transmit  Capability  to  VTS  Operations 


(This  page  intentionally  left  blank.) 


Acquisition  Directorate 

Research  &  Development  Center 


A-2 


rnclitviilicd  l  W-Vlh  RIH  I  Gonin.  cl  ;il  I\<V1K 

Public  Murch20|() 


Alternatives  Report  for  Transition  of  Prototype  AIS  Transmit  Capability  to  VTS  Operations 


APPENDIX  B.  VTS  PORTS  IMPLEMENTATION  COST  MODEL 

The  team  identified  a  number  of  cost  categories  to  aid  in  the  estimation  of  the  cost  to  transition/implement 
the  enhanced  capability  at  all  12  VTS  ports.  These  cost  categories  are  described  in  each  of  the  sub-sections 
below. 

B.l  Overall  Assumptions 

Some  specific  assumptions  related  to  each  of  the  cost  components  are  described  in  the  relevant  sections. 
Some  overall  assumptions  are  listed  here.  In  addition. 
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Table  25  lists  some  costs  that  are  used  in  all  options. 

1)  Tampa  and  LA/LB  have  the  Norcontrol  software  and  not  PAWSS. 

2)  Installing  PAWSS  is  not  an  option  at  Tampa  or  LA/LB  (financial/political  constraints). 

3)  VTS  Louisville  does  not  have  PAWSS,  CGVTS,  or  Norcontrol  software.  There  are  no  plans  to 
install  PAWSS  at  VTS  Louisville. 

4)  San  Francisco  and  Puget  Sound  are  treated  as  PAWSS  ports  in  this  analysis. 

5)  Options  1  and  3-5  only  apply  to  PAWSS  ports  (total  of  9).  For  these  options  Tampa,  LA/LB,  and 
Louisville  remain  as  in  Option  2. 

6)  Under  Option  2,  no  cost  savings  is  made  for  the  fact  that  Tampa  has  some  equipment  already 
installed;  i.e.  computer  and  network  costs  are  included  for  Tampa  along  with  the  other  1 1  ports. 

7)  Under  the  base  options,  it  is  assumed  that  the  non-standard  software  cannot  be  used  on  the  CGDN+ 
(need  separate  network  access).  This  assumption  is  relaxed  in  the  sub-options  with  an  appropriate 
CGDN+  certification  cost  added. 

8)  A  composite  average  VTS  port  is  used  for  costing  (and  then  the  cost  for  this  multiplied  by  the 
number  of  VTS  ports)  rather  than  trying  to  determine  costs  for  each  VTS  port  individually. 

9)  An  average  number  of  4  AIS  base  stations  at  each  VTS  port  is  used. 

10)  Data  back-up  is  something  that  may  be  needed  in  the  future,  but  for  this  report  no  cost  has  been 
included  for  a  data  backup  system. 

1  l)No  costs  have  been  factored  in  for  spares  or  for  the  C2CEN  baseline. 
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Table  25.  Costs  used  in  all  options. 


Item 

Cost/yr 

Server 

$2,000 

Desktop 

$1,000 

Network  Installation  cost/line 

$250 

Network  cost/line/year 

$1,200 

Onsite  Hourly  labor  rate 

$150 

1  MD  =  $1 50/h  x  8hrs 

$1,200 

CGDN  Certification 

$50,000 

additional  cost 

CGDN+  certification 

reduced  costs 

can  eliminate  network  expenses 
both  yearly  and  installation  costs 

OSC  hardware  costs  -  per  site  -  assuming  4 
sites  per  OSC  computer 

$500 

OSC  costs/site/year  for  monitoring 

$50,000? 

OSC  costs/site/year  for  initial  response 

$20,000? 

B.2  Initial  transition/installation  costs 

These  are  the  one-time  costs  involved  with  the  initial  transition  and  installation  of  the  transmit  capability  at 
all  VTS  ports.  This  includes  hardware  purchase  and  installation,  software  development  and  documentation, 
and  network  line  ordering  and  installations.  Some  of  these  costs  for  each  option  are  listed  in  Table  26. 


Table  26:  Some  installation  Assumptions  for  each  Option. 


Server 

Desktop 

VTS  Network 
Access 

AIS  Base  Station 
Network  Access 

Option  2 

A  server  is  needed  for 
the  back-end 
processes  -  if  not 
included  in  PAWSS 

A  desktop  computer  is  needed  for 
the  message  creation/display 
software  -  if  not  included  in 

PAWSS 

A  local  network 
line  is  needed  for 
each  VTS 

Network  lines  are 
needed  for  every  AIS 
base  station  (3  per 
site) 

Option  3 

A  server  is  needed  for 
the  back-end 
processes  -  if  not 
included  in  PAWSS 

A  desktop  computer  is  needed  for 
the  message  creation/display 
software  -  if  not  included  in 

PAWSS 

A  local  network 
line  is  needed  for 
each  VTS 

Option  4 

A  server  is  needed  for 
the  back-end 
processes  -  if  not 
included  in  PAWSS 

A  local  network 
line  is  needed  for 
each  VTS 

Option  5 

A  local  network 
line  is  needed  for 
each  VTS 
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B.2.1  Installation  assumptions 

1)  A  server  is  needed  for  the  back-end  processes  if  not  included  in  PAWSS  (options  2-4). 

2)  A  desktop  computer  is  needed  for  the  message  creation/display  software  if  not  included  in  PAWSS 
(options  2-3). 

3)  Software  development  work  is  needed  on  the  existing  RDC  software  (FF/QM/ARI)  to  make  the 
applications  operationally  ready  and  to  add  self-monitoring  capability.  All  of  the  capability  also  must 
be  documented. 

4)  In  option  2,  network  lines  are  needed  for  every  AIS  base  station  (3  per  site).  This  includes  initial 
installation  costs  as  well  as  monthly  service  costs. 

5)  In  options  2-5  a  local  network  line  is  needed  for  each  VTS.  This  includes  initial  installation  costs  as 
well  as  monthly  service  costs.  Even  though  the  two  non-standard  VTSs  may  already  have  a  usable 
network  connection,  costs  are  included  for  all  12  VTSs. 

6)  Installation  costs  include  preparing  for  each  site,  arranging  for  the  network  lines,  and  onsite  time 
(travel  costs  are  not  included  in  this  estimate). 

7)  Site  survey  time  is  not  included;  it  is  assumed  that  personnel  at  each  VTS  will  provide  the  necessary 
information  ahead  of  time  and  perform  any  site  preparation  necessary. 

8)  The  hardware  associated  with  each  installation  will  be  shipped  to  each  respective  VTS.  It  is  assumed 
that  the  VTS  will  assist  with  regards  to  receiving  and  storing  the  hardware  shipped. 

B.3  Training 

There  will  be  costs  associated  with  training  personnel  to  use  the  new  capabilities.  This  includes  preparation 
of  training  materials  and  the  initial  training. 

B.3.1  Training  assumptions 

1)  Cost  estimates  for  training  encompass  only  training  material  development  and  initial  training. 

2)  Any  refresher  training  will  be  integrated  as  part  of  the  PQS/watchstander  training  program  and  thus 
there  are  no  recurring  training  costs. 

3)  As  the  system  matures  and  capabilities  are  added,  training  documentation  will  be  updated  under 
existing  or  future  maintenance  contracts. 

B.3.2  Training  development 

The  development  will  include  the  creation  of  training  documentation  and  a  syllabus  that  reflects  the  training 
objectives.  The  documentation  must  be  clear  and  concise  so  it  can  be  referenced  by  VTS  watchstanders 
even  after  the  initial  training  has  been  completed  after  installation.  The  training  must  cover  any  knowledge 
and  skills  that  the  onsite  support  personnel  must  have  to  enable  them  to  provide  initial  support.  Often 
training  materials  are  used  as  reference  materials  by  end  users,  thus  the  documentation  should  be  able  to 
stand  on  its  own  in  this  regard.  Training  must  be  provided  on  all  new  software  and  capabilities,  back-end 
software  monitoring  (FF/QM)  and  message  creation/display  regardless  of  whether  the  capability  is  added  to 
PAWSS  or  resides  in  separate  applications. 
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B.3.3  Initial  training 

The  VTS  watchstanders  and  support  personnel  will  have  to  be  trained  in  the  support  and  operation  of  the 
AIS  software  after  installations.  Watchstanders  and  watch  supervisors  should  be  trained  to  completely 
understand  the  AIS  software  and  how  to  properly  use  it.  This  would  include  a  comprehensive  overview'  of 
enhanced  AIS  and  it’s  capabilities  and  the  proper  use  of  things  such  as  message  creation  and  system 
monitoring. 

The  support  personnel  have  the  added  responsibility  of  being  able  to  perform  Level  1  troubleshooting, 
defined  as  initial  response,  problem  evaluation  and  plan  of  action  to  fix  the  problem.  They  must  recognize 
when  they  need  to  escalate  the  troubleshooting  to  Level  II,  which  is  defined  as  requesting  assistance  from 
offsite  assets  (separate  contract  support  for  AIS  software,  computer  maintenance,  and  network 
maintenance). 

B.4  Maintenance 

These  are  the  costs  to  maintain  the  system  for  5  years.  Support  in  this  report  is  broken  down  into  three 
categories:  Hardware,  Software,  and  Software  Maintenance.  Hardware  will  mean  the  actual  servers  and 
desktop  machines  associated  with  the  implementation  of  the  AIS  capabilities.  Software  will  mean  any 
current  AIS  software  or  developed  AIS  software,  depending  on  which  model  is  selected  for  transition. 
Software  Maintenance  is  defined  later  in  this  document. 

B.4.1  Maintenance  assumptions 

1)  Maintenance  support  is  assumed  to  be  7x24x365  with  initial  response  handled  by  onsite  personnel 
and  second-tier  response  handled  by  contract  with  a  time-to-respond  of  4  hours  and  time  to  repair  of 
24  hours. 

2)  Onsite  (VTS)  personnel  will  do  routine/initial  response  (reboot  computer,  restart  software,  call  Dell, 
call  AT&T  etc). 

3)  Maintenance  costs  will  be  based  upon  on  a  5-year  contract. 

4)  Basic  computer  support  is  included  in  the  purchase  of  hardware  (5-year  onsite  support). 

5)  Network  issues  fall  under  the  purview  of  network  service  provider;  any  network  outages  resulting  in 
the  need  for  repair  which  are  clearly  the  responsibility  of  the  network  provider  will  not  be  included 
in  the  costing. 

6)  A  maintenance  contract  will  be  initiated  for  AIS  software  support. 

B.4.2  Hardware  Support 

It  is  assumed  that  any  computer  equipment  will  be  purchased  with  an  extended  5-year  onsite  repair  warranty 
from  the  manufacture.  There  will  be  an  additional  upfront  cost  (usually  around  20%  added  to  the  price  of 
the  computers)  but  it  is  well  worth  it.  If  there  are  failures  with  these  computer  components,  the  manufacture 
will  be  responsible  for  repairing  the  computers  with-in  a  24  hour  time  period. 
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B.4.3  Software  Support 

Support  for  the  software  will  be  a  broken  down  into  two  levels  of  response  needed.  Onsite  (VTS)  personnel 
w  ill  perform  the  first  level  of  support.  If  an  operator  cannot  immediately  resolve  an  issue  with  the  PAWSS 
or  Alion  AIS  software,  they  will  request  immediate  assistance  from  the  on-site  contracted  support  staff.  If  it 
is  a  computer  hardware  problem  they  will  initiate  a  warranty-repair  call  with  the  PC  manufacturer.  If  it  is  a 
network  outage  they  will  initiate  a  trouble-call  to  the  network  provider.  An  average  of  0.5  man-hour  per 
computer  per  week  will  be  used  to  estimate  the  Level  I  support.  This  does  not  mean  there  will  always  be  one 
instance  a  week,  but  over  time  it  is  estimated  that  26  hours  a  year  is  what  would  be  expected  as  a  first  level 
support  service.  It  is  assumed  that  existing  onsite  personnel  can  accomplish  this  additional  tasking  during 
the  normal  course  of  operations  so  no  costs  have  been  included  in  the  comparisons;  these  costs  will  be 
addressed  under  the  Personnel  section. 

Level  II  support  will  be  performed  by  contract  support.  It  is  assumed  that  the  current  and  future  contracts  for 
PAWSS  by  Lockheed  Martin  will  include  the  support  for  the  added  AIS  functions.  If  there  is  any  RDC 
software,  then  support  will  be  provided  by  contract;  costs  are  estimated  based  on  3  instances  per  computer 
per  year  at  4  hours  per  incident  (12  hours  per  year  per  computer).  There  is  either  zero  (option  5),  one  (option 
4)  or  two  (options  2-3)  computers  at  each  site  for  the  non-PAWSS  software. 

B.4.4  Software  Maintenance 

Software  Development  has  many  phases.  See  reference  [6]  for  background  information.  These  phases 
include  Requirements  Engineering,  Architecting,  Design,  Implementation,  Testing,  Software  Deployment, 
and  Maintenance.  Maintenance  is  the  last  stage  of  the  software  life  cycle.  After  the  product  has  been 
released,  the  maintenance  phase  keeps  the  software  up  to  date  with  environment  changes  and  changing  user 
requirements.  Maintenance  consists  of  four  types,  which  can  characterize  all  changes  to  the  system: 

•  Corrective  maintenance  deals  with  fixing  bugs  in  the  code.  Corrective  maintenance  is  ‘traditional 
maintenance’  while  the  other  types  are  considered  as  ‘software  evolution.’ 

•  Adaptive  maintenance  deals  with  adapting  the  software  to  new  environments. 

•  Perfective  maintenance  deals  with  updating  the  software  according  to  changes  in  user  requirements. 

•  Preventive  maintenance  deals  with  updating  documentation  and  making  the  software  more 
maintainable. 

All  6  of  the  proposed  models  will  require  all  four  aspects  of  software  maintenance.  The  industry  standard 
for  an  annual  cost  that  is  typically  paid  to  the  software  vendor  to  maintain  their  software  averages  18-25% 
of  the  software  license  cost  annually.  For  purposes  of  this  report,  20%  of  the  development  cost  associated 
with  the  software  used  in  each  model  will  be  the  standard.  Since  the  PAWSS  software  is  already  under  a 
maintenance  contract  it  is  assumed  that  any  new  functionality  added  to  PAWSS  would  also  be  covered 
under  this  contract  at  no  extra  charge. 
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B.5  Facilities 

Normally  the  cost  of  facilities  support  is  included  in  any  cost  estimation  when  considering  the  addition  of 
systems  or  equipment.  While  Enhanced  AIS  under  most  configurations  does  add  one  to  two  computers  and 
their  associated  peripherals,  it  is  assumed  that  there  wall  be  space  available  at  each  of  the  VTS  centers  for 
these  computers,  therefore,  there  are  not  any  costs  associated  with  facilities  in  the  overall  budget  for  the 
individual  configurations  in  this  report. 

B.5.1  Facilities  assumptions 

1)  Space  is  available  at  each  VTS  for  the  additional  1  or  2  computers  and  display  and  no  additional  cost 
is  included  in  the  costing  for  space  or  furniture. 

2)  UPS  (power)  will  be  provided  by  the  VTS  and  is  not  included  in  the  cost. 

3)  Other  factors  that  are  commonly  considered  as  additional  cost  such  as  power  requirements  and  loads 
on  A/C  will  be  minimal  and  will  have  zero  impact  on  the  existing  cost  the  facilities  currently  incur 
on  a  monthly  basis. 


B.6  Personnel 


Onsite  personnel  will  be  called  upon  to  perform  the  message  creation,  basic  system  monitoring,  and  initial 
response.  This  amount  of  time  (and  thus  cost)  is  common  across  all  options.  Since  it  is  outside  the  scope  of 
this  report  to  determine  whether  each  VTS  can  absorb  this  extra  workload  without  impacting  operations,  we 
have  chosen  to  report  the  required  FTE  here  but  not  include  the  cost  into  the  cost  tables. 

Site  Survey/Prep:  This  is  assumed  to  take  about  40  hours  per  site.  If  this  were  to  be  contracted  out  this 
would  add  $72K  to  the  cost. 


Message  Creation:  In  the  short  term  the  AIS  transmit  capability  will  not  save  time  as  the  existing 
communications  methods  will  still  have  to  be  used  in  parallel  with  the  binary  transmissions.  This  will 
continue  until  mariners  can  all  receive  the  binary  transmissions.  Therefore,  the  time  to  create  the  binary 
messages  is  an  addition  to  the  workload.  I  he  amount  of  time  to  create  an  Area  Notice  message  is  a  function 
of  the  complexity  of  the  area  and  the  experience  of  the  operator.  On  average  though,  an  Area  Notice  should 
be  able  to  be  created  in  2-3  minutes.  There  are  probably  only  1  or  2  messages  per  VTS  per  day  that  would 
need  to  be  created  (each  one  might  be  transmitted  for  a  couple  of  days  at  a  fairly  rapid  rate  but  this  does  not 
take  operator  interaction  once  it  is  created).  Waterways  Management  messages  consist  of  2  parts  the  static 
and  the  list.  The  static  part  might  take  2  minutes  to  create,  but  only  needs  to  be  done  once.  The  list  part 
might  take  2-3  minutes  to  create;  these  would  be  created  and  sent  more  often  -  perhaps  as  many  as  20  per 
day.  Total  rough  time  estimate  is  about  414  hours  per  year  per  site.  This  is  thus  about  0.2  FTE  per  site  (per 
year)  or  a  total  of  2.4  FTE  per  year  for  all  12  sites. 


Onsite  Monitoring:  This  is  assumed  to  take  about  1/2  man-hour  per  day  per  site  (10  min  per  watch).  This  is 
thus  0.0625  FTE  per  site  (per  year)  or  0.75  FTE  total  per  year  for  all  12  sites.  If  this  were  to  be  contracted 
out  this  would  add  ~$1.64M  to  the  cost  over  5  years. 


Initial  Response:  Using  the  assumptions  described  above  in  maintenance  this  is  0.5  hour  per  week  per  site. 
This  is  thus  0.0125  FTE  per  site  or  0.15  FTE  total  per  year  for  all  12  sites.  If  this  were  to  be  contracted  out 
this  would  add  $234K  to  the  cost  over  5  years. 
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B.7  CGDN+  Option 

An  additional  sub-option  to  consider  for  each  option  is  to  get  CGDN+  certification  for  the  back-end  process 
software.  Under  all  options  additional  network  lines  are  added  to  the  VTS  and  to  the  AIS  Base  stations  in 
option  2;  if  the  processes  were  certified  then  existing  CGDN+  connections  could  be  used.  For  this  sub¬ 
option  the  costs  associated  with  the  network  lines  are  removed  and  a  fixed  cost  for  CGDN  certification  is 
added. 

B.8  Centralization  Option 

One  option  considered  was  whether  to  centralize  some  processes.  The  FF  and  QM  processes  for  each  VTS 
could  be  moved  to  OSC  Martinsburg  where  they  could  be  centrally  managed  and  monitored.  In  order  for  the 
back-end  processes  to  be  moved  to  OSC  they  would  need  to  be  certified  to  be  on  the  CGDN+  so  the  cost 
increases  and  savings  described  in  the  preceding  section  all  apply  here  as  well.  Centralization  would  also 
allow  some  minor  reductions  in  the  per  site  cost  by  allowing  for  fewer  computers  to  be  used.  The  major 
difference  would  be  in  the  monitoring  and  initial  response  costs.  For  applications  hosted  at  OSC 
Martinsburg  there  would  be  a  charge  for  this.  If  the  assumption  is  true  that  that  these  activities  could  be 
absorbed  by  the  onsite  VTS  personnel  at  no  cost  then  this  makes  Centralization  much  more  expensive.  If 
however,  the  true  costs  of  the  monitoring  and  initial  response  were  used  as  described  under  the  Personnel 
section,  then  centralization  would  be  the  much  more  cost-effective  option  (maybe  $120K/year  vs 
$328.5K/year!).  This  would  apply  to  options  2-4. 
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